分布式光伏項目年總結，分布式總結TODO

本文作為分布式學習的一個提綱和總結，目前只是隨筆，尚未添加文章分類

分布式光伏項目年總結。要想做一個完善的分布式系統，至少要有下面這幾種組件
1.遠程過程調用
2.分布式同步服務
3.安全認證
4.文件系統
5.資源管理系統 k8s
6.集群管理系統 運維
7.集群監控系統 運維

實現分布式事務，只有三種方式
1.鎖：動態的執行事物間的串行順序，順序與要鎖的對象有關，在一定長度上限制了并發的可能性，其實就是影響一定的效率

電商分布式架構圖？2.樂觀并發控制：假設所有事務都不相互影響，只有在提交的時候，才驗證，就是說驗證是最后一道程序，如果出現異常，想要回滾，相對來說比較麻煩，如果不出現異常，樂觀并發控制是性能較好的，如果出現異常，則性能很差

3.時間戳排序：靜態的決定了串行順序，順序與事務開啟的順序有關（注意與鎖的區別），言外之意就是哪個事務先開啟，就哪個事務先執行，很大程度的限制了并發的可能，其實就是效率很低

分布式事務架構，所有的分布式都一定是這種架構，必須有兩種角色
（1）事務的協調者coordinator，
（2）事務的參與者

牢記上述兩種角色，接下來闡述事務提交協議的演變

單階段原子提交協議：參與者事務的提交和放棄都是協調者說了算，不允許參與者單方面放棄事務，這樣就會導致如果參與者掛了，就會死鎖，如果死鎖，協調者就沒辦法解決

二段提交：為了支持參與者單方面放棄事務，出現了二段提交協議
（1）準備階段，也叫投票階段，過程如下
（1.1）協調者向所有參與者詢問能否提交請求
（1.2）

1. 如果參與者回復yes，則參與者必須將本次事務改變的對象以及自己的各種狀態，都存儲到持久性介質當中，例如存到某個文件上，或者mysql中，通通可以理解存到硬盤上，回復完畢之后，必須等待協調者進一步指示（此時被參與者的狀態被稱作"不確定的狀態"），在等待期間，參與者除了繼續詢問協調者結果之外，無法做其他的事情，協調者一段時間內沒有回復，則認為協調者宕機，此時應該執行事務回滾（單方面放棄事務）
2. 如果參與者回復no，參與者立即放棄事務（意味著后來其他參與者也會因為該參與者的放棄而回滾）

（2）完成階段，協調者根據階段1的結果，決定告訴所有參與者是提交事務還是放棄事務，參與者操作完畢之后，返回haveCommited狀態

缺點：比方A是協調者，B參與者，A給B發了doCommit，然后A掛了，此時B執行commit，返回給A，此時A重啟之后，已經無法接到B是成功還是失敗

其實解決這個問題我個人覺得很簡單的辦法就是A重啟之后，再詢問B是成功還是失敗，不過業界普遍采用的方式是三段提交

三段提交：將二段提交的12階段之間，增加一個preCommit階段，也叫準備提交階段
（1）協調者向所有參與者發送準備提交preCommit命令
如果發送之后，協調者掛了，沒關系，所有參與者都沒有doCommit，協調者可以從新發送preCommit
如果發送之后，某個參與者掛了，沒關系，協調者感知到之后，通知所有參與者撤銷事務
（2）完成階段，就是之前說的二段提交協議的完成階段
如果發送之后，協調者掛了，沒關系，選出新的協調者，新的協調者發現當前是完成階段，那么告訴其他參與者，沒有doCommit的繼續，已經doCommit的告訴我已經完成

日記：會不會有參與者不知道自己是否已經doCommit呢？？不會，但是為什么不會，因為目前我的知識還不清楚單機事務是如何實現的，總之既然能實現單機事務，那么就足以說明這個假設不成立