1. 性能和時延問題 在服務(wù)化之前，業(yè)務(wù)通常都是本地API調(diào)用，本地方法調(diào)用性能損耗較校服務(wù)化之后，服務(wù)提供者和消費者之間采用遠(yuǎn)程網(wǎng)絡(luò)通信，增加了額外的性能損耗： 1） 客戶端需要對消息進(jìn)行序列化，主要占用CPU計算資源。
創(chuàng)新互聯(lián)公司專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、圍場網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計、商城系統(tǒng)網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為圍場等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
php的在頁面載入時或調(diào)用session_start()時從數(shù)據(jù)源中讀取session數(shù)據(jù)到$_SESSION變量。
當(dāng)頁面執(zhí)行完畢或調(diào)用session_write_close()時把$_SESSION變量寫入數(shù)據(jù)源。
php默認(rèn)的session.save_handler=files，可以通過文件鎖來實現(xiàn)讀寫同步，保證session數(shù)據(jù)的一致性，不會產(chǎn)生問題。然而當(dāng)使用sqlite作為session handler時，由于沒有同步機(jī)制，會產(chǎn)生bug。如下代碼：
test1.php
PHP code?
session_start();
$_SESSION['data1'] = 'data1';
sleep(10);
session_write_close();
test2.php
PHP code?
session_start();
$_SESSION['data2'] = 'data2';
session_write_close();
在同一瀏覽器進(jìn)程里（保證使用相同的session_id），先訪問test1.php，再訪問test2.php，會發(fā)現(xiàn)data2根本沒有寫入sqlite數(shù)據(jù)庫中。session.save_handler=memcache還沒有測試，估計也有這個問題。如果采用默認(rèn)的files handler會發(fā)現(xiàn)test2.php的請求會被掛起直至test1.php執(zhí)行完畢，這就是文件鎖同步機(jī)制造成的。
我想到了兩種解決方案：
1、實現(xiàn)互斥鎖，保證同一session_id訪問session數(shù)據(jù)是同步的，這樣會產(chǎn)生一個阻塞的問題（php默認(rèn)的session實現(xiàn)也會有這個問題）。
2、寫入session數(shù)據(jù)時進(jìn)行數(shù)據(jù)合并，不過這樣仍然不能完全保證數(shù)據(jù)一致性。
不會，這里的原子性不要從php的角度看，應(yīng)該從redis的角度看，同一個redis節(jié)點對并發(fā)的請求都是序列化處理的，所以單操作不存在你擔(dān)心的并發(fā)問題，但如果是read write的形式到哪里都不行了，切記。
有人問到read write是啥，其實就是并發(fā)的一個經(jīng)典問題，代碼如下
$v = $redisClient-get('v');
$v ++;
$redisClient-set('v', $v);
就是先讀取數(shù)據(jù)，再修改數(shù)據(jù)，在寫回修改，這里是希望每次訪問都遞增v的值，但在并發(fā)情況下，兩個進(jìn)程都讀取到了一樣的初始值，比如3，然后都加1變?yōu)?，最后把4寫回Redis，這種情況就會統(tǒng)計數(shù)據(jù)比實際的少。盡量都用Redis的原子操作就好，比如incr。
微服務(wù)架構(gòu)的流行源于它能夠帶來更快的變化響應(yīng)能力，比如獨立部署，每個服務(wù)的能力職責(zé)是獨立的，可以按需獨立發(fā)布；再比如每個服務(wù)可以由不同的開發(fā)團(tuán)隊負(fù)責(zé)，每個服務(wù)的技術(shù)棧也可以不同，可以選擇更快捷合理的方式實現(xiàn)不同的服務(wù)。
然而，微服務(wù)架構(gòu)作為分布式架構(gòu)，躲不開的一個問題就是數(shù)據(jù)一致性的問題，特別是在技術(shù)異構(gòu)和數(shù)據(jù)源類型不同的情況下，傳統(tǒng)的分布式事務(wù)（2PC或3PC）也很難解決微服務(wù)架構(gòu)下的一致性問題。
在微服務(wù)架構(gòu)下，多個服務(wù)之間通常會定義明確上下游關(guān)系，下游系統(tǒng)可以依賴上游系統(tǒng)，下游系統(tǒng)可以通過API查詢或修改上游系統(tǒng)的數(shù)據(jù)；反過來則不然，上游系統(tǒng)不應(yīng)該知道下游系統(tǒng)的存在，也就是說上游系統(tǒng)不能依賴下游系統(tǒng)，上游系統(tǒng)的變化只能通過異步事件的方式發(fā)出，下游系統(tǒng)監(jiān)聽事件并基于事件做對應(yīng)的數(shù)據(jù)狀態(tài)變化。
在基于上面原則的微服務(wù)架構(gòu)下（見上面圖示，本文不考慮服務(wù)間循環(huán)依賴的場景），在上下游服務(wù)間的數(shù)據(jù)通信（圖示中的每個箭頭表示一種數(shù)據(jù)通信）一旦發(fā)生問題，都會產(chǎn)生數(shù)據(jù)不一致的場景，下面我們逐一說明：
舉個例子，訂單服務(wù)是下游服務(wù)，庫存服務(wù)是上游服務(wù)，在訂單確認(rèn)時要鎖定庫存，實現(xiàn)上訂單服務(wù)在狀態(tài)變化同時通過同步API修改庫存的狀態(tài)，為了保證數(shù)據(jù)一致性，在調(diào)用庫存服務(wù)API異常后訂單服務(wù)會回滾當(dāng)前的數(shù)據(jù)狀態(tài)變更。
在這個場景下，同一個業(yè)務(wù)流程，需要同時修改兩個服務(wù)的數(shù)據(jù)，在以下兩種情況下會發(fā)生數(shù)據(jù)不一致的問題：
上游服務(wù)每個關(guān)鍵狀態(tài)變更都可能觸發(fā)下游服務(wù)的一些邏輯鏈，因此上游服務(wù)發(fā)布的事件對于下游服務(wù)是非常重要的，但這些事件并不影響上游服務(wù)自身邏輯，也不影響自身數(shù)據(jù)狀態(tài)的變化，因此通常不會設(shè)計成阻礙業(yè)務(wù)流程，那么在事件服務(wù)或事件載體（通常是消息隊列）與上游服務(wù)之間的通信異常，就會導(dǎo)致上游服務(wù)的事件發(fā)布失敗。
這種場景下，上游服務(wù)的業(yè)務(wù)流程已經(jīng)成功，不可能有再次觸發(fā)事件的場景，這個事件就丟失了，下游服務(wù)因為沒有收到上游服務(wù)的事件，數(shù)據(jù)沒有做對應(yīng)的變化而導(dǎo)致數(shù)據(jù)一致性問題。
同樣，下游服務(wù)在消費事件時也很有可能因為一些原因，導(dǎo)致事件的消費失敗，這些原因可能包括：
上游服務(wù)并不關(guān)心下游的消費者，所以對于發(fā)布出去的事件，上游系統(tǒng)也不關(guān)心下游服務(wù)是否消費成功，更不會有因某個下游服務(wù)消費失敗而重發(fā)事件的邏輯，這同樣會導(dǎo)致類似于場景二的數(shù)據(jù)一致性問題。
根據(jù)CAP理論，分區(qū)容錯性、可用性和一致性里面必須要犧牲掉一個，而在實際實現(xiàn)過程中，分區(qū)容錯性和可用性是很難舍棄的，所以通常會舍棄一致性，取而代之會用最終一致性保證數(shù)據(jù)在可容忍的時長內(nèi)達(dá)到最終一致。
微服務(wù)架構(gòu)也不例外，在服務(wù)內(nèi)部，可以通過本地事務(wù)保證數(shù)據(jù)的強(qiáng)一致性；而當(dāng)業(yè)務(wù)發(fā)生在多個服務(wù)中，我們追求最終一致性。那么都有哪些措施可以保證跨服務(wù)的最終一致性呢？
這是個業(yè)務(wù)問題，在微服務(wù)的架構(gòu)下，每個服務(wù)都是獨立的，如果有一個業(yè)務(wù)功能需要同時修改兩個服務(wù)的數(shù)據(jù)，往往這個業(yè)務(wù)可以拆分成兩個步驟，比如場景一種提到的訂單和庫存的例子，如果我們可以先鎖定庫存，然后再確認(rèn)訂單看上去這個問題就迎刃而解了。
因此在業(yè)務(wù)中發(fā)現(xiàn)一個功能需要同時修改兩個服務(wù)的數(shù)據(jù)，我們首先可以來討論這個業(yè)務(wù)設(shè)計是否合理；如果業(yè)務(wù)上很多場景都要求兩個服務(wù)的數(shù)據(jù)保持強(qiáng)一致，那可能我們需要看看微服務(wù)的劃分是否合理。
為了解決場景二和場景三的不一致性問題，需要上游服務(wù)和下游服務(wù)的共同努力：
上游服務(wù)需要盡可能將事件發(fā)送出去，比如：先同步發(fā)送，如果失敗改為異步重試，重試多次仍然失敗可以先持久化，通過定時任務(wù)來重發(fā)或者人工干預(yù)重發(fā)。
下游服務(wù)也要盡可能的把事件處理掉，收到事件后可以考慮先將事件持久化，消費成功后標(biāo)記事件，如果消費失敗可以通過定時任務(wù)重試消費。
當(dāng)我們提到重試，就不得不考慮冪等性的問題，這里的冪等性包括以下兩個場景：
即便我們做了很多我們認(rèn)為萬全的準(zhǔn)備，在分布式系統(tǒng)的執(zhí)行鏈路上，每個節(jié)點都有可能失敗，加上業(yè)務(wù)的復(fù)雜度，數(shù)據(jù)不一致的情景也很難徹底解決，而對于那些小概率發(fā)生但技術(shù)解決起來成本昂貴的問題，我們可以嘗試通過對業(yè)務(wù)的深刻理解設(shè)計一些后臺的數(shù)據(jù)維護(hù)功能，保證在核心業(yè)務(wù)數(shù)據(jù)異常時，可以在一定的規(guī)則內(nèi)進(jìn)行修復(fù)，從而保證業(yè)務(wù)的順利進(jìn)行
數(shù)據(jù)一致性問題首先是個業(yè)務(wù)問題，其次才是個技術(shù)問題。在微服務(wù)架構(gòu)下，我們期望每個服務(wù)職責(zé)單一，這種職責(zé)單一體現(xiàn)的是業(yè)務(wù)價值，如果微服務(wù)的拆分過小而導(dǎo)致業(yè)務(wù)難以實現(xiàn)，那這種拆分是不合理的，業(yè)務(wù)專家們非常有必要了解系統(tǒng)，從業(yè)務(wù)側(cè)給出服務(wù)拆分的建議。
在數(shù)據(jù)一致性問題上，我們首先要思考業(yè)務(wù)設(shè)計的合理性，其次是當(dāng)前架構(gòu)設(shè)計的合理性，然后在一定的約束下，通過最終一致性保證業(yè)務(wù)價值，除非迫不得已，不建議引入分布式事務(wù)框架，一方面成本較高，另一方面也會引入性能等新的問題。
重慶分公司
重慶分公司
