打油詩：
公司小，沒有自己的食堂；
夏天熱，不願出去吃飯；
我們於是都訂飯!
人人都訂飯，我們做軟體；
訂餐軟體好，大家頂得高；
每天多幾份，雷鋒不見了！
都等別人打**訂飯，雖然系統中錄入了n多條資訊，依然有些不方便。 話說
我們訂飯的人很多，最終有人做了個訂飯的系統，但是在如何選擇誰在某天訂飯的問題上出現了分歧！
於是我寫了以下的具體方案：
【方案原始目標】
讓所有人公平地享用訂飯系統；
【解決方案原型】
每乙個人新增兩個字段，n吃飯的總次數，服務於別人的人次數m
結論：1、m/n 是 服務係數
4、道義上講：服務係數越大的人越雷鋒
最終結論：服務係數最小的訂飯。當幾個人一樣的情況下，隨機選擇乙個（只需要top 1即可）
【存在的問題】
人初始化的時候資料出現了0次作為被除數，這個時候應該給乙個特例，吃飯次數為0的，服務係數為1；
【設計方案】
1 資料庫層
表關鍵字段：user(userid, username, eatingcount,helpothercount)
select top 1 userid,username from user t1 inner join
(select min(case eatingcount when 0 then 1 else helpothercount/eatingcount end) v
from user )t2
on (case eatingcount when 0 then 1 else helpothercount/eatingcount end) = t2.v
2 介面層
當訂飯完畢後更新資料：即訂飯的介面增加乙個按鈕，誰點誰訂飯
點完後做如下計算和操作：
分布式系統事務解決方案選擇
解決方案一 使用 alibaba seata 可以來解決 但是該種解決方案 不適合 大併發情況下，會影響效能，使用於管理後台各個微服務呼叫的增刪改查的事務管理 解決方案二 使用 mq 來解決，保證資料的最終一致性 如 在電商系統中，當下乙個訂單後，要扣減庫存，我們先遠端呼叫 庫存介面，有可能會出現，...
分布式系統解決方案（五） 快取的選擇
描述 快取雪崩是指快取中資料大批量到過期時間，而查詢資料量巨大，引起資料庫壓力過大甚至down機。解決方案 1 快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生。2 如果快取資料庫是分布式部署，將熱點資料均勻分布在不同搞得快取資料庫中。3 設定熱點資料永遠不過期。描述 快取穿透是指快取和...
某大型銀行深化系統技術方案之十五 服務層之服務呼叫
傳送門 android兵器譜 服務層 服務層主要體現了soa體系下的元件復用和業務復用機制。服務的邊界定義決定於粒度和耦合度。粒度表示的是乙個服務的大小，它可以理解為服務操作的範圍，粗粒度的服務，操作的內容廣而且雜 細粒度的服務，操作的內容細而且簡單。粗粒度的服務設計，可以減小服務之間的耦合性，但付...