今年又參加了一次系統(tǒng)架構(gòu)師考試，幾乎可以肯定的說(shuō)，過(guò)不了，盡管還看了那么幾天書(shū)，回想起來(lái)，主要還是自己的功底不扎實(shí)，題目雖然有那么點(diǎn)點(diǎn)難。
選擇題是沒(méi)有什么問(wèn)題，但論文與分析應(yīng)用題沒(méi)做好，以至于現(xiàn)在還是耿耿于懷。
題目： 1. nosql 數(shù)據(jù)庫(kù)的應(yīng)用經(jīng)歷及優(yōu)點(diǎn)（我寫的論文）
? ? ? ? ? ? 2. SOA?架構(gòu)的層次說(shuō)明及應(yīng)用（有點(diǎn)微服務(wù)的味道）
? ? ? ? ? ? 3.?數(shù)據(jù)流程圖填空（房東、租客、中介平臺(tái)等）UML（其實(shí)很基礎(chǔ)，但記不清楚，慘呀）
? ? ? ? ? ? 4.?系統(tǒng)嵌入式設(shè)計(jì)中的消息通信（基本上不懂）
? ? ? ? ? ? 5. redis?與 memcache?的區(qū)別及redis幾種分布式存儲(chǔ)，redis集群的幾種方式（簡(jiǎn)述應(yīng)用題）
好了，題目講完了，我挑了（1），（5）題
論文題目，NoSQL的應(yīng)用，我把工作中用大數(shù)據(jù)庫(kù)計(jì)算銷量預(yù)測(cè)的事情說(shuō)一下，先放個(gè)圖
出了考場(chǎng)我就后悔，怎么能寫hive呢，改成hbase也會(huì)好點(diǎn)呀，不說(shuō)了。
第（5）題，redis與memcache 的區(qū)別我還知道點(diǎn)，
redis有持久化，memcache不支持。。。。。但說(shuō)到redis的幾種分布式存儲(chǔ)，我就不清楚了，只知道m(xù)aster-slave，說(shuō)不出幾種來(lái)。而集群方式，就寫分片，哨兵。事后我越想越不對(duì)，就認(rèn)真查了一下，正確的答案應(yīng)該是這樣的。
集群方式
1. 客戶端分片
優(yōu)點(diǎn)
不使用第三方中間件，實(shí)現(xiàn)方法和代碼可以自己掌控并且可隨時(shí)調(diào)整。這種分片性能比代理式更好(因?yàn)樯倭朔职l(fā)環(huán)節(jié))，分發(fā)壓力在客戶端，無(wú)服務(wù)端壓力增加
缺點(diǎn)
不能平滑地水平擴(kuò)容，擴(kuò)容/縮容時(shí)，必須手動(dòng)調(diào)整分片程序，出現(xiàn)故障不能自動(dòng)轉(zhuǎn)移，難以運(yùn)維
2.?Twemproxy，Codis
twitter開(kāi)源的Twemproxy
Codis是一個(gè)豌豆莢團(tuán)隊(duì)開(kāi)源的使用Go語(yǔ)言編寫的Redis Proxy
優(yōu)點(diǎn)
運(yùn)維成本低。業(yè)務(wù)方不用關(guān)心后端 Redis 實(shí)例，跟操作 Redis 一樣。Proxy 的邏輯和存儲(chǔ)的邏輯是隔離的
缺點(diǎn)
a. 代理層多了一次轉(zhuǎn)發(fā)，性能有所損耗
b. 進(jìn)行擴(kuò)容/縮容時(shí)候，部分?jǐn)?shù)據(jù)可能會(huì)失效，需要手動(dòng)進(jìn)行遷移，對(duì)運(yùn)維要求較高，而且難以做到平滑的擴(kuò)縮容
c. 出現(xiàn)故障，不能自動(dòng)轉(zhuǎn)移，運(yùn)維性很差
redis version >= 3.0 ,?redis-trib(ruby）?
優(yōu)點(diǎn)
a. 無(wú)中心節(jié)點(diǎn)
b. 數(shù)據(jù)按照 Slot 存儲(chǔ)分布在多個(gè) Redis 實(shí)例上
c. 平滑的進(jìn)行擴(kuò)容/縮容節(jié)點(diǎn)
d. 自動(dòng)故障轉(zhuǎn)移(節(jié)點(diǎn)之間通過(guò) Gossip 協(xié)議交換狀態(tài)信息,進(jìn)行投票機(jī)制完成 Slave 到 Master 角
色的提升)
e. 降低運(yùn)維成本，提高了系統(tǒng)的可擴(kuò)展性和高可用性
缺點(diǎn)
a. 嚴(yán)重依賴外部 Redis-Trib
b. 缺乏監(jiān)控管理
c. 需要依賴 Smart Client(連接維護(hù), 緩存路由表, MultiOp 和 Pipeline 支持)
d. Failover 節(jié)點(diǎn)的檢測(cè)過(guò)慢，不如“中心節(jié)點(diǎn) ZooKeeper”及時(shí)
e. Gossip 消息的開(kāi)銷
f. 無(wú)法根據(jù)統(tǒng)計(jì)區(qū)分冷熱數(shù)據(jù)
g. Slave“冷備”，不能緩解讀壓力
優(yōu)點(diǎn)
Smart Client：
a. 相比于使用代理，減少了一層網(wǎng)絡(luò)傳輸?shù)南模瘦^高。
b. 不依賴于第三方中間件，實(shí)現(xiàn)方法和代碼自己掌控，可隨時(shí)調(diào)整。
Proxy：
a. 提供一套 HTTP Restful 接口，隔離底層存儲(chǔ)。對(duì)客戶端完全透明，跨語(yǔ)言調(diào)用。
b. 升級(jí)維護(hù)較為容易，維護(hù) Redis Cluster，只需要平滑升級(jí) Proxy。
c. 層次化存儲(chǔ)，底層存儲(chǔ)做冷熱異構(gòu)存儲(chǔ)。
d. 權(quán)限控制，Proxy 可以通過(guò)秘鑰控制白名單，把一些不合法的請(qǐng)求都過(guò)濾掉。并
且也可以控制用戶請(qǐng)求的超大 Value 進(jìn)行控制，和過(guò)濾。
e. 安全性，可以屏蔽掉一些危險(xiǎn)命令，比如 Keys、Save、Flush All 等。
f. 容量控制，根據(jù)不同用戶容量申請(qǐng)進(jìn)行容量限制。
g. 資源邏輯隔離，根據(jù)不同用戶的 Key 加上前綴，來(lái)進(jìn)行資源隔離。
h. 監(jiān)控埋點(diǎn)，對(duì)于不同的接口進(jìn)行埋點(diǎn)監(jiān)控等信息。
缺點(diǎn)
Smart Client：
a. 客戶端的不成熟，影響應(yīng)用的穩(wěn)定性，提高開(kāi)發(fā)難度。
b. MultiOp 和 Pipeline 支持有限。
c. 連接維護(hù)，Smart 客戶端對(duì)連接到集群中每個(gè)結(jié)點(diǎn) Socket 的維護(hù)。
Proxy：
a. 代理層多了一次轉(zhuǎn)發(fā)，性能有所損耗。
b．進(jìn)行擴(kuò)容/縮容時(shí)候?qū)\(yùn)維要求較高，而且難以做到平滑的擴(kuò)縮容
redis分布式存儲(chǔ)的幾種方式 ？?至今不清楚，感覺(jué)和集群的概念有點(diǎn)混
哨兵的作用就是對(duì)Redis的系統(tǒng)的運(yùn)行情況的監(jiān)控，它是一個(gè)獨(dú)立進(jìn)程。它的功能有2個(gè)：
1、?監(jiān)控主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)是否運(yùn)行正常；
2、主數(shù)據(jù)出現(xiàn)故障后自動(dòng)將從數(shù)據(jù)庫(kù)轉(zhuǎn)化為主數(shù)據(jù)庫(kù)；
但是哨兵不能動(dòng)態(tài)地?cái)U(kuò)容。
