## 問題 1. 注冊中心 eureka, zk，consul 和 nacos，做對比？ 就分布式一致性協議角度出發，zk和consul都是CP確保一致性和容錯性的；eureka和nacos是AP確保高可用和容錯性的。（nacos還可以做為配置中心使用，選擇CP模式） 就實現語言角度出發，Consul是go語言實現，其他3個都是Java實現。 就健康檢查支持而言，4個都支持，zk是KeepAlive 生態支持，nacos支持sc集成，dubbo集成，k8s集成。  2. 為什么nacos更適合做注冊中心？ * nacos的服務注冊和下線快，基于消息機制通知客戶端變更本地緩存的注冊表信息。 * nacos支持多環境配置，可以通過namespace，Group等區分不同環境。 * 支持生態全，支持springcloud等，dubbo集成，k8s集成等。 3. 博弈論 * 海盜分金  反向推理： - 首先到了4號提出的方案的時候肯定是最終方案，因為不管5號同意不同意都能通過，所以4號5號不必擔心自己被投入大海。那此時5號獲得的金幣為0，4號獲得的金幣為100。 - 5號：因為4號提方案的時候 ，自己獲取的金幣為0 。所以只要4號之前的人分配給自己的金幣大于0就同意該方案。 - 4號：如果3號提的方案一定能獲得通過（原因：3號給5號的金幣大于0， 5號就同意 因此就能通過），那自己獲得的金幣就為0，所以只要2號讓自己獲得的金幣大于0就會同意。 - 3號：因為到了自己提方案的時候可以給5號一金幣，自己的方案就能通過，但考慮到2號提方案的時候給4號一個金幣，2號的方案就會通過，那自己獲得的金幣就為0。所以只要1號讓自己獲得的金幣大于0就會同意。 - 2號：因為到了自己提方案的時候只要給4號一金幣，就能獲得通過，根本就不用顧及3 號 5號同意不同意，所以不管1號怎么提都不會同意。 - 1號：2號肯定不會同意。但只要給3號一塊金幣，5號一塊金幣（因為5號如果不同意，那么4號分配的時候，他什么都拿不到）就能獲得通過。 答案：98，0，1，0，1 4. 分布式事務？ 多數據源的數據一致性需要分布式事務保障。 分布式事務的實現有很多種協議，如Oracle的XA協議，有二階段提交和3階段提交兩種實現。 二階段提交： 階段：準備和提交。 缺點： 1. 性能不好，資源占用高。未提交或者回滾，數據庫資源會一直被占用。 2. 協調者故障，導致運行中的事務無法繼續完成。 3. 丟失消息導致數據不一致性，一部分節點收到提交消息，另一部分沒收到提交消息。 3階段提交：