- 總摘要: 事務. Kafka. 并發. 分布式事務落地. 一致性Hash.
2017-11-15
- 摘要: 事務. Kafka. 并發.
1. 電商的很多業務，考慮更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即為了滿足高負載的用戶訪問，我們可以容忍短暫的數據不一致。那怎么做呢？
- 第一，不做分布式事務，代價太大。
- 第二，不一定需要實時一致性，只需要保證最終的一致性即可。
- 第三，“通過狀態機和嚴格的有序操作，來最大限度地降低不一致性”。
- 第四，最終一致性（Eventually Consistent）通過異步事件做到。
如果消息具有操作冪等性，也就是一個消息被應用多次與應用一次產生的效果是一樣的話，那么把不需要同步執行的事務交給異步消息推送和訂閱者集群來處理即可。假如消息處理失敗，那么就消息重播，由于冪等性，應用多次也能產生正確的結果。
實際情況下，消息很難具有冪等性，解決方法是使用另一個表記錄已經被成功應用的消息，即消息隊列和消息應用狀態表一起來解決問題。
2. 事務消息
杭州–小神(-) 11:49:07
最終一致性適合一致性要求不高的場合。強一致性的，這種就要蛋疼點.
北京-竹竿(-) 11:57:14
@杭州–小神 你們使用的什么MQ
上海-下一秒升華(-) 11:58:33
第六步本地事務提交成功，第七步mq commit失敗，這種情況怎么辦？
北京-屁顛顛(-) 12:47:07
順序有要求的吧
北京-屁顛顛(-) 12:47:38
現在基本都是mq 來做補償事務吧
北京-屁顛顛(-) 12:48:42
自動補償都要根據自家業務定制的
廣州-小護士(-) 12:50:09
所以消息的可靠傳輸就很重要~
3. Kafka 開放性問題[西神]
- 我有個疑問，kafka種，生產者可以設置· min.insync.replicas，然后broker也可以設置，而且這兩個值還可能不一樣。比如生產者設置1，而broker設置為2，意思就是生產者認為有一個副本成功就算成功，那broker的意思是要2個副本成功才算成功，那這個不是矛盾了么。還有，生產者怎么知道寫入成功，還不是要broker給返回吧，那broker設置的是2，如果2個沒寫完，它如何返給生產者結果呢?
- 它說如果生產者設置為1，broker設置為2，那么當生產者發送了消息給leader，leader馬上就返回說成功，但是此時leader還沒同步到副本自己就掛了，此時ISR會選一個成為leader，但是這個leader對于之前發送的消息并不存在，因為之前leader還沒同步給它就掛了，這樣一來整個集群就丟了消息，而生產者確認為我寫入消息是成功的，于是造成了不一致.
北京-ylh(-) 20:13:33
不可能100%不丟吧
南京-劉(-) 20:16:17
應該會丟 目前了解的一個系統用的kafka還配套了補償機制
成都-梅小西(-) 20:16:23
你們在寫kafka的時候設置了重試機制么，一般重試幾次
北京-屁顛顛(-) 20:18:22
2
4. 對于防止并發，在整個系統中，什么方案比較好點呢？[成都-..累狠久ㄋ(-) ]
成都-..累狠久ㄋ(-) 21:44:07
重復并發，在整個系統中，什么方案比較好點呢？
成都-梅小西(-) 21:44:24
那不就是冪等么
成都-..累狠久ㄋ(-) 21:44:33
就是重復的線程，會造成重復的數據在DB里
上海--小蟲(-) 21:44:46
隊列
成都-..累狠久ㄋ(-) 21:45:29
比如在數據庫集群的情況下又如何處理呢？
成都-獻計獻策(-) 21:49:33
防止并發？并發為什么要防止？
成都-梅小西(-) 21:49:45
重復數據，要么單線程，要么db做唯一驗證
成都-梅小西(-) 21:49:51
要么代碼里加鎖
成都-..累狠久ㄋ(-) 21:50:08
要做負載均衡，
成都-梅小西(-) 21:50:09
你得舉個詳細的例子才能幫你
成都-..累狠久ㄋ(-) 21:50:45
就是比如一個接口，要發送銷售訂單數據，然后防止他提交重復的數據。類似這種把。當然也有從界面新增的數據,如果客戶點了兩次，那么也可能發生這樣的事
成都-梅小西(-) 21:51:48
表里面做了唯一索引么
成都-(-) 21:53:15
點兩次這種操作在前端可以限制撒
成都-..累狠久ㄋ(-) 21:53:17
主鍵默認要采用唯一索引
成都-梅小西(-) 21:53:22
你的意思是，2個應用有可能發送同一條數據進db里？
成都-梅小西(-) 21:53:28
你做了負載均衡
成都-梅小西(-) 21:54:26
這是一種辦法
成都-..累狠久ㄋ(-) 21:55:46
但是重復的并發，也會損耗性能的
成都-..累狠久ㄋ(-) 21:56:41
這只能方式重復的DB數據.
廣州-后覺(-) 21:57:03
分布式鎖
成都-梅小西(-) 21:57:09
db做唯一索引最方便
成都-梅小西(-) 21:57:34
還有種方法，單線程，比如通過mq，或者通過分布式鎖
成都-..累狠久ㄋ(-) 21:58:17
分布式鎖，太慢啦
成都-梅小西(-) 21:58:22
還有一種方式，db的共享鎖，前提條件是需要索引，不需要唯一索引, 這種方式我用過
成都-梅小西(-) 21:58:56
你的詳細情況我不了解無法具體幫你
成都-..累狠久ㄋ(-) 21:59:13
嗯嗯，已經幫了很多。我結合實際情況看哈
成都-梅小西(-) 22:02:19
你可以把你的情況把敏感數據去掉然后給我們一個實例，我們才能幫你
成都-..累狠久ㄋ(-) 22:03:06
暫時只是考慮這種情況。還沒開發
成都-..累狠久ㄋ(-) 22:04:29
其實在mvc層有個tocken可以解決重復提交
成都-..累狠久ㄋ(-) 22:05:10
對于接口之間的重復并發，還有DB的確實之前不知道
成都-..累狠久ㄋ(-) 22:06:22
但是如果是分庫的話，
成都-梅小西(-) 22:07:15
分庫沒關系啊，同一個訂單數據最終會到同一個表啊
成都-梅小西(-) 22:07:27
只要在同一個表，就可以控制
成都-梅小西(-) 22:07:41
再說了，就算不在一個表，也有辦法
成都-..累狠久ㄋ(-) 22:08:08
如果不在一個表怎么弄好點呢？
成都-..累狠久ㄋ(-) 22:08:35
如果有4個庫，剛好4條重復到4個庫中的話，該怎么辦呢？
成都-梅小西(-) 22:09:02
那只能走單線程了，比如同樣的訂單排隊
成都-梅小西(-) 22:09:06
不同的訂單不用排隊
成都-..累狠久ㄋ(-) 22:10:07
怎么操作的呢？
成都-梅小西(-) 22:10:53
分布式鎖，同樣的訂單，比如用訂單唯一性字段做key
成都-..累狠久ㄋ(-) 22:10:58
這樣就需要判斷是否是相同的訂單
成都-梅小西(-) 22:11:49
我擦，你不是說了有重復數據么，你用你的重復標準做key不就行了
成都-..累狠久ㄋ(-) 22:12:03
嗯是的
廣州-Frank(-) 22:12:08
你這就是冪等，你去查下如何做冪等
杭州-jiwliu(-) 22:12:33
你這是什么應用場景，確定涉及到4個庫這么大嗎？
杭州-jiwliu(-) 22:13:06
前端可以用一些防止表單重復提交的手段
成都-..累狠久ㄋ(-) 22:13:08
打個比方, 有些數據不走前端
廣州-Frank(-) 22:13:18
都不關數據量的問題，他主要是防止重復提交
廣州-Frank(-) 22:14:15
你是想說直接調用接口提交嗎
上海-中紀委(-) 22:28:32
放在後臺做比較好點
深圳-rubin(-) 22:29:22
做冪等就行啦
成都-梅小西(-) 22:33:37
我總覺得前端做重復校驗解決不了根本問題
成都-梅小西(-) 22:33:43
確實可以繞過
深圳-rubin(-) 22:34:28
前端不可信
廣州-后覺(-) 22:35:06
前端最好也做，后端一定要做
上海--海棠(-) 22:39:40
防止表單重復提交，后端是要做的
深圳-wjc(-) 22:42:07
后端要做這個保護。
北京-liunx(-) 22:42:10
前后都做比較好吧。
深圳-wjc(-) 22:42:19
但是前臺肯定也要做啊
2017-11-16
- 摘要: 分布式事務落地 , 一致性Hash
1. 這種分布式事務落地的方案，哪位大佬有落地過嗎？
北京-屁顛顛(-) 9:44:40
這種分布式事務落地的方案，哪位大佬有落地過嗎？
深圳-山峰(-) 9:46:10
本地消息表可以，但是我們這邊現在有點問題，就是本地消息表寫太頻繁了，讀的時候有問題
成都-梅小西(-) 9:47:08
這種方式貌似用的挺多
成都-梅小西(-) 9:47:15
用本地表+消息
成都-梅小西(-) 9:47:26
廣州-小護士(-) 9:47:29
用本地緩存寫消息，異步寫入消息表
北京-屁顛顛(-) 9:50:18
好像這種要不同的業務部門對這個消息表，進行對賬，不知是不是這樣
北京-竹(-) 9:50:35
對賬，是不好些？
成都-OOXX(-) 9:51:54
消息事務表 比如 扣庫存 下單 這兒有個事務表
那么 下單后 消費優惠劵這里 又得有個事務表？
深圳-waiter(-) 9:52:03
這里最好應該不要撤銷操作 而是重試 [圖片上傳失敗...(image-3ab5da--)]
北京-屁顛顛(-) 9:52:54
這個事務表怎么搞，也不太清楚
成都-OOXX(-) 9:53:33
優惠劵后面 要是再來個加積分或者什么的服務 還得有個事務表？
北京-遇見(-) 9:54:01
B系統往A系統發送消息這種也是走mq?
北京-屁顛顛(-) 9:54:23
聊聊分布式事務，再說說解決方案
北京-屁顛顛(-) 9:55:55
@成都-OOXX 我們也有積分和折扣
成都-梅小西(-) 10:03:25
要么就不要這么復雜，直接走補償算了
成都-梅小西(-) 10:03:34
凡是沒成功的，都記錄下來
北京-屁顛顛(-) 10:04:25
本地消息表（異步確保） 這個就是走補償的
北京-遇見(-) 10:04:38
@成都-梅小西 B系統往A系統發送消息這種也是走mq?
北京-漫游(-) 10:05:49
補償的話得保證冪等
北京-喜(-) 10:06:58
分布式事務就一定不需要做冪等？
北京-屁顛顛(-) 10:09:26
那個本地消息表，不是為了做冪等的嗎？
廣州-端茶倒水(-) 10:13:10
有重試吧，跑批
2. 項目中最有挑戰的技術點, 一致性hash. 如何保證分布式一致性, 如何跟蹤一個請求. etag, lastmodified, perm增長, 如何定位. 討論. [成都-梅小西]
杭州-小剛(-) 20:19:33
第三個延伸起來東西還是比較多的，可以搞一個鏈路追蹤系統
北京-哇咔咔(-) 20:20:26
一致性哈希我抄的jedis
北京-哇咔咔(-) 20:21:02
第二個可以用raft 細節記不住
北京-竹竿(-) 20:21:15
其實我想問，一致性hash加節點
上海-給你們(-) 20:21:54
單服務的鏈路跟蹤寫通用組件不來就不好寫，分布式鏈路跟蹤還是有技術含量的
北京-竹竿(-) 20:21:54
本身沒什么好討論的，加減節點時候 可以討論
北京-哇咔咔(-) 20:22:13
Trace span prevspan記日志用來追蹤
上海-給你們(-) 20:22:41
記日志比較low
北京-哇咔咔(-) 20:22:47
Perm 增長可能是動態類太多，檢查有哪些動態類生成了一直沒回收
北京-哇咔咔(-) 20:23:13
你們怎么追蹤的
北京-哇咔咔(-) 20:24:17
加減節點，重新創建一致性哈希環
上海-給你們(-) 20:25:21
之前接觸過一個風控項目，用bcel動態埋點，有些過一些代碼
上海-給你們(-) 20:32:38
開發cat的時候寫的動態埋點，然后分布式鏈路這個是衍生的服務，扔es里做鏈路查詢
北京-竹竿(-) 20:34:04
鏈路跟蹤 只有異步遇到線程池值得討論
上海-給你們(-) 20:34:43
分布式和異步的場景是一樣的
北京-竹竿(-) 20:34:52
不一樣
成都-梅小西(-) 20:35:16
我有個疑問，設置為自動提交offset，是在拿到消息后會自動提交還是我處理完了這個消息才會自動？
成都-獻計獻策(-) 20:36:56
業務上消息處理失敗，要存下來
成都-獻計獻策(-) 20:37:05
等待重試
成都-梅小西(-) 20:38:15
你們是自動還是手動
北京-ylh(-) 20:38:30
自動
3. mysql 時間類型存儲
2017-11-17
- 摘要: 分布式事務落地 , 一致性Hash
1. 項目使用Mycat分庫，在mycat中分為多個schema；是否可以通過MyBatis的Interceptor指定SQL執行的schema？ [北京-java菜鳥-天下]無果
2. 有一場景，監控平臺統計，存放日志數據，但各個系統的日志信息格式可能不一樣，存量估計在5000W左右，請大家幫忙提提建議. [深圳-安分]
深圳-安分<-> 16:24:27
選 用mongodb可行嗎？
北京-wdm(-) 16:25:14
es也可以嘛
成都-勇(-) 16:26:21
感覺ELK就是為你定做的
深圳-心陽(-) 16:48:47
選用mongodb會卡死的，這個適用少量不規則數據。es也可以存放不規則數據啊，只是多寫幾個實體. 選型ELK(ElasticSearch, Logstash, Kibana)
