最有效率的分布式是在執行方法前知道所執行的方法使用的資料即所謂環境，
並把相關資料和方法本法放到指定的機器上執行，
返回結果給指定的客戶端。
在方法本身不確定的前提下，所有資料都是環境一部分。
如果使用統一資料伺服器的方法，網路和硬碟的開銷抵消了分布式的優勢。
因為大部分操作無外乎就是把資料簡單操作後放到新的資料裡。
cpu計算所佔比例較低（需要資料支援）
如果每個機器乙個環境，環境的同步過程，資料通訊也非常驚人。
在退一步說，對所有方法使用的資料縮小範圍，
使用語言限定的方法提前獲知方法使用的資料範圍，把範圍內的資料從環境內提取
運算結束後放回環境。
這樣做在多cpu環境下可能會產生一些問題。
總之這是cpu使用率和匯流排使用率的平衡問題，
我們究竟是cpu使用的更多還是資料交換使用的更多。
在增加伺服器的同時也增加了通訊的成本，這裡的開銷成本指硬體和軟體的兩方面。
能否填補cpu的使用線性增加還有待考察。
微服務分布式事務的一些思考
關於微服務分布式事務的一些思考，筆者沒有參與過複雜分布式事務的場景，各位大神路過可以分享一些遇到的案例，大家一起 關於分布式事務，筆者推薦的處理方法是 盡量避免 如果實在避免不了 這已經是高併發 使用者量比較多的 了 則使用 最終一致性 處理 參照cap理論base思想 如果處理了事務，但還是遇到了...
分布式 一些問題
1 有使用過快取嗎？redis和memcached有什麼區別？2 redis的執行緒模型？單執行緒的redis如何實現高效能的？3 使用redis實現過分布式鎖嗎？什麼是分布式鎖 4 有什麼其他方式實現分布式鎖嗎？zk實現的和redis有何區別？5 zk實現的分布式鎖如何解決網路抖動的鎖丟失導致的併...
對分布式一些理解
1，微服務的優缺點 微服務的解決的問題，吞吐量，易擴充套件，小模組的快速開發，解決單點故障多。缺點，單個請求的反應時間變長，需要通過rpc調取多個下游服務。部署整條鏈路複雜，排錯，定位問題複雜。架構邏輯複雜。2，分布式一些難點 1，容易出錯，所以需要把錯誤當成正常邏輯，寫在 裡。能處理的，不能處理的...