總摘要: 讀寫分離. mysql RR
2017-12-11
- 摘要: 讀寫分離. mysql RR.
1. 你們數據庫做了讀寫分離嗎? 做讀寫分離，什么情況下要做讀寫分離呢? 你們判斷是否要讀寫分離是怎么判斷的? [上海--海棠]
廣州-小護士<-> 9:14:03
讀寫分離看場景.
Netflix的場景：
多數據園區，需要園區之間高度同步。需要寫同步很快的數據庫
于是選擇了寫最快的Cassandra, Netflix是面向全球服務的場景.單單是美國就有至少兩個園區，東區和西區. Cassandra出名的讀很慢, 所以使用了 Memcache.
成都-梅小西(-) 9:16:34
讀寫分離一般是高并發系統優化的第一步
北京-天空<->
@上海--海棠 加緩存，簡單粗暴
廣州-小護士<-> 9:17:23
高并發是個相對概念
上海--海棠(-) 9:17:31
日訂單數量10萬算不算
廣州-小護士<-> 9:17:41
用戶請求數 比 接受請求的線程總數
成都-梅小西(-) 9:17:52
10萬要看是不是集中在某幾個小時, 如果是分散的，還算不上高并發. 讀寫分離是大部分系統優化的第一步。這只能暫時解決, 往后光靠讀寫分離是不夠的.
上海--海棠(-) 9:22:53
現在我們系統在搞優化，沒什么經驗
廣州-小護士<-> 9:23:06
Netflix棧：
Cassandra， 寫快讀慢。解決需求：多數據園區高頻同步。
Memcache，讀快寫快，緩存技術。解決需求：Cassandra讀慢。
之所以用Memcache 而不用Redis，是由于背后應用架構的選擇：微服務，粒度過細的服務.
廣州-小護士<-> 9:24:47
我還有個案例，我還記得的，交通銀行。
成都-梅小西(-) 9:25:48
交通銀行怎么了
蘇州-winylee(-) 9:26:02
直接寫Memcache，數據會不會丟失
北京-天空<-> 9:26:07
在數據庫訪問這層加緩存@上海--海棠 ，一層不夠再加一層
廣州-小護士<-> 9:26:19
交通銀行棧：
DB2，歷史的選擇。寫慢讀慢，但是夠穩定，幾十年沒出事。
Gemfire，NewSQL，當做緩存。解決需求：DB2寫慢讀慢的缺點，采用定時異步更新data到DB2
成都-梅小西(-) 9:26:43
緩存用gemfire？這玩意好用么
廣州-小護士<-> 9:26:55
為什么選擇Gemfire。場景：
網絡支付，實時轉賬，給DB2帶來很大的壓力. Gemfire是Pivotal家的東西。要收費。
杭州－東子(-) 9:26:53
加緩存吧, 讀者分離先別考慮了
成都-梅小西(-) 9:28:30
我的意思是gemfire跟redis，mem這種相比，是不是更牛逼, 招行的技術棧呢
廣州-小護士<-> 9:29:15
Gemfire提供了類SQL的查詢引擎
廣州-Ryan(-) 9:33:55
讀寫分離和緩存解決的問題都類似，帶來的問題也同樣，比如數據一致性，業務上容忍不？出問題的兜底方案怎樣？
想清這些問題就好下手
2. 問個問題，MySQL RR 解決了幻讀？[杭州-微笑]
廣州-天道(-) 10:12:15
mysql RR解決了幻讀的
杭州-微笑(-) 10:14:07
好像并不完全？
比如A 事務先查一次，然后B 事務插入一條記錄，A 事務更新該記錄，然后再查一次，此時讀到了這條新插入的被更新的記錄。
成都-凌落(-) 10:15:56
RR通過 多版本管理解決了幻讀問題的
深圳-Foxleg(-) 10:16:28
事務已經遇到平頂了， 繼續打通任督二脈啊。
成都-孤狼(-) 10:16:31
你這個問題問的，你先去看看RR
杭州-微笑(-) 10:17:53
RR 不就是讀到的一行數據不變嗎
北京-Shenandoah(-) 10:18:34
開啟事務之后， 其他會話對數據庫的操作，讓當前會話不可見。
成都-凌落(-) 10:18:46
發現有寫操作 讀操作 看到的就是歷史版本
杭州-微笑(-) 10:20:56
更新操作操作的是select 操作沒查到的數據，更新完，select 里多了，不是幻讀嗎
上海-coty(-) 10:22:04
你可以自己嘗試下嘛。
上海-coty(-) 10:22:09
比這樣問好多啦。
北京-Shenandoah(-) 10:22:14
好好搜索一下，建議使用Google
杭州-微笑(-) 10:23:25
試驗過了
杭州-微笑(-) 10:23:30
我就問問，這個算不算幻讀
杭州-微笑(-) 10:25:11
左邊A 事務，右邊B 事務，A 事務先做了select，B 事務提交之后，A做了左邊的操作
成都-梅小西(-) 10:26:02
@杭州-微笑 不會的啊。rr下a還是讀的老數據，不會讀到b數據
上海-coty(-) 10:26:14
commit 事物不是已經提交啦么 ？
成都-梅小西(-) 10:26:32
他沒說a提交啊
上海-coty(-) 10:27:05
a也沒讀到b的修改啊
杭州-微笑(-) 10:27:14
b 做了插入
杭州-微笑(-) 10:27:32
a 更新了這條插入的數據，再查就查到了
成都-梅小西(-) 10:28:17
a都沒查到b插入的時候，如何更新？
成都-梅小西(-) 10:28:20
數據
杭州-微笑(-) 10:29:17
b 插入了id 14 的記錄，a 直接更新id 14 的數據，然后再查就查到了
杭州-光明消逝(-) 10:30:18
這個不是數據庫事務基礎么, 無非就是時間節點, 查詢,其它事務提交 (再查詢可以查到14,但忽略了),然和14提交
成都-梅小西(-) 10:31:04
你自己試過么, 你設置了不要自動提交么
杭州-微笑(-) 10:32:18
截圖是我實驗的結果,都是事務中操作的, A 那邊提交完再查又不一樣
杭州-小五(-) 10:34:16
意思是：首先你得關閉自動提交，再實驗
杭州-微笑(-) 10:37:03
回頭試試，不過直覺和這不會有關系
成都-梅小西(-) 10:38:56
我靠，當然有關系啊，你沒設置關閉自動提交？
上海-coty(-) 10:41:00
必須有關系啊
上海-coty(-) 10:41:06
rr 講的是在一個事物內啊
杭州-微笑(-) 10:44:11
取消事務自動提交的結果一樣
杭州-海妖(-) 11:09:31
mysql RR用gap lock解決了幻讀的問題
深圳-scaler(-) 11:15:16
你這個B的插入事務都提交了，A當然能看到了
杭州-微笑(-) 11:15:48
更新前，是看不到的
成都-梅小西(-) 11:16:15
@深圳-scaler 胡說。這是rr。b就算提交了，a也看不到
杭州-微笑(-) 11:16:31
是的
2017-12-13
- 摘要: zk選舉. 問題排查.
1. zk 選舉機制有哪些缺點？zk選舉的羊群效應具體是怎么樣子的？[廣州-小護士]
廣州-小護士9:56:49
但是我不明白里面說的receive notification，那么誰去通知 leader failed？為了避免羊群效應，整個zk集群節點構成一個雙鏈鏈表。leader failed 了 誰去通知 leader的next node。讓這個next node 去執行 getChildren 從而拿到全部children list ？同時又是怎么保證這個通知可達?
杭州-微笑(-) 10:03:00
是監聽
廣州-小護士<-> 10:03:09
是不是還有一個類似 monitor的節點但并非是zk集群中的成員, 這個monitor會輪詢監聽那個leader是不是failed了
杭州-微笑(-) 10:03:16
后一個節點監聽前一個, 一個節點變化只會引起后一個節點的動作. 那個curator 里的工具算法是這樣的.
北京-Mr.Win(-) 10:05:20
我只是建議所以反問你，學東西就應該自己多問問自己，然后再對比一下別人怎么做的，特別是你有疑惑的時候
廣州-小護士<-> 10:31:03
zk 集群會有腦裂問題嗎
成都-蘇連云(-) 10:31:10
不會 , 選舉 n/2+1個才能成為leader
北京-天空<-> 10:31:28
會有腦裂啊
廣州-小護士<-> 10:32:10
出現腦裂，如何處理？n/2+1 election，然后呢?
成都-蘇連云(-) 10:33:58
如果集群一半宕機,選舉不出來leader的
成都-梅小西(-) 10:36:24
那就直接宣告集群掛掉, 可以參考下redis哨兵的選舉
廣州-小護士<-> 10:40:38
沒看到哪里文檔有說zookeeper集群掛一半然后不能找leader. quorum 是法定人數，這個人數就是剛才說的 n/2 + 1 ？不滿足條件就取消 leader activation，然后重新選舉？
2. 請問一個面試問題, 沒有任何日志的前提情況下, 怎么排查服務器上一個 Java 應用為何莫名其妙的掛掉了呢？ [廣州-John]
廣州 - Cyan(-) 13:16:40
沒日志 看個啥 . 都是說空話，瞎猜
廣州-John(-) 13:17:49
嗯 這種感覺 Linux 應該多多少少會留下點蛛絲馬跡,Nginx Tomcat Java 這些都沒有任何的 log
深圳-wjc<-> 13:42:22
沒日志應該不是查把。。。應該是猜。。。
廣州-John(-) 13:43:33
嗯 當時有點蒙 但是后面覺得可以結合 Linux 和 監控 可以反查
廣州-小護士<-> 13:56:53
實際上, john遇到的問題需要充另外一角度去解決，有點像黑客思維
廣州-小護士<-> 13:57:24
如果那個進程有對外訪問服務的, 可以查對應消費者的日志, 假設那個進程有被消費者定時輪詢訪問的，可以嘗試查查那個消費者的日志
廣州-小護士<-> 13:59:17
如果宕掉的進程本身是在docker 容器環境下運行的，可以查查docker自身的容器日志, 感覺考察的不是縱向思維，而是發散性思維，考察對各種情況的可能性，有點像 detect
廣州-Ryan(-) 14:00:49
都是偵探，服務器不掛，進程沒有了，先查服務器日志，比如被oom killed了。
如果沒有，看看有沒辦法看命令操作日志，比如人為的kill。
上海-story(-) 14:03:00
我想問下 面試官后面給出答案了嗎
廣州-John(-) 14:03:09
沒有
