樂視
他們的全域性ID生成採用Snowflake,並且附加了分庫分表資訊.
也就是說,根據全域性ID,就可以知道該資訊具體存在哪個資料庫中.

比如 userid mod 8 然後拼接在 Snow ID之前
這樣透過 GID的前幾位,就可以知道分庫資訊.
但是一旦資料庫擴容,ID就會很麻煩.
所以他們一般mod很大的數字
比如 userid mod 128 拼接 Snow ID

另外,他們最終一致性,將分庫的資訊,彙總到一個總庫,然後對比.
感覺有點繁瑣.

最後,樂視的架構師說分庫不能無限擴充套件,
因為每個中介軟體都需要連線所有的分庫.
這樣隨著中介軟體,資料庫的增多.
每個中介軟體獲得的每個資料庫的連線會越少.因為每個資料庫的最大連線數量都是有上限的.
所以一般採用微服務拆分,由上層服務決定,分配到哪個微服務處理.
而微服務,只是連線自己的那個資料庫就可以了.

58沈劍
最終一致性三種寫入方式
1.同步寫,寫完A庫,寫B庫
缺點
寫B庫失敗,A庫如何處理?
假如寫A庫,B庫,最後在提交A庫,B庫.
則連線和鎖的佔用時間,都增大了

2.同步寫一個庫,非同步寫另外一個庫..(這個..看著眼熟)

3.同步寫A庫,離線非同步寫B庫.(透過Canel抽)

事務補償三種方式
1.全量掃資料對比
2.掃描增量日誌(就是掃描translog和msglog)
3.實時比對
每次寫A庫或者寫B庫,都傳送一個訊息到訊息佇列,然後由一個消費者程式,同時收到兩個訊息,則認為事務完成.否則超時事務補償.
但是這個訊息佇列的可靠性由什麼保證呢.也是一個麻煩的事情.

參加Gdevops總結

相關文章