1樓：唐陽
首先微服務不是碎服務
別什麼都拆開
真的有需要分布式事務的一般是2/3pc
這裡假設你是mysql
聯合查詢在互分布式資料庫裡面本來就很難做
網際網路服務幾乎不會使用聯合查詢
2樓：起名難
以微服務為代表的分布式系統上，不適合事務性操作，因為分布式事務的效率非常的差。所以現在最終一致性的概念越來越受到關注。當然，最終一致性與事務操作相比，效率上有優勢，但不能時刻保持資料一致性。
總體來說是為了效率，做出了一定的妥協。
簡單來說，要是對效率要求較低，可以使用兩階段提交協議，來保證分布式事務一致性。但是效能較差，不能滿足高併發場景。要是可以接受短時間的資料不一致，只要最終保證資料一致性，那就可以利用MQ等技術來提高系統的吞吐量。
要是又想高效，又想分布式事務一致性，暫時沒有解決方案。
分布式事務？No, 最終一致性
最終一致性的另一種選擇
分布式系統事務一致性解決方案
一致性與可用性：Werner Vogels談最終一致性訊息「時序」與「一致性」為何這麼難？
微服務架構中可以直接使用資料庫作為註冊中心嗎？
小小笑兒 可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心 類似 eureka 三觀成型沒法改 可以其實大多數公司連日均8000pv的訪問坎都過不去，my...
微服務的資料庫怎樣劃分？總不能很多微服務使用同乙個資料庫吧，那不是和單體服務一樣了？
liujunsong 這個問題的沒有標準答案，各家怎麼做的都有，都有道理，都對。要回答這個問題，先要回答另乙個問題，就是，資料庫設計的原則是什麼？或者說資料儲存設計的原則是什麼？而不是把這個問題偷梁換柱成，微服務的資料庫如何劃分，微服務是對外的展現形式，而資料儲存是資料層的儲存設計。這是兩個完全層面...
資料庫的 Buffer Pool 如何提高並行度？
李晨曦 既然鎖的粒度太大了，最簡單的方法就是減小鎖的粒度就好了，你的實現是全域性鎖，這種肯定慢，執行緒數多的時候甚至比單執行緒還慢。改成範圍鎖或者槽鎖就能夠大幅度提公升效能了，hashtable的每個槽一把鎖，操作page id對映到同乙個槽的page時才會有衝突，否則是沒有鎖衝突的。極端情況下所有...