We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
發現 DDIA 看的越多,才對整個公司的 Service 有更進一步的了解 (例如: Data Pipeline 用 ZK 當作時間進度的控制器有線性一致的好處等等),之前考慮的往往都是『ZK 是一個很有名大家都在用的分散式調度系統』,並不會去思考背後達到了什麼的一致性或避免了什麼併發問題。
但看完最近幾章就發現要考慮的面向其實挺多的,最後又想到在讀 Cracking System Design 這類的文章,都會發現他們也都是把常見的 component 拿來討論大概都怎麼設計,並不會著墨到這麼底層的一致性問題 (自己以前在實做也是就拿常見的 Design Pattern 實做特定系統),所以就滿好奇實際上設計一個大型依賴系統是會真的考慮到這麼細緻的嗎 XDD
The text was updated successfully, but these errors were encountered:
通常會先用錢來解決。 KK:拿別人建置好的環境,每個月花點錢處理(想成每個月花錢請一個 DevOps 幫你解決)
強一致性主要是在金融方便才會非常強調。
Sorry, something went wrong.
No branches or pull requests
發現 DDIA 看的越多,才對整個公司的 Service 有更進一步的了解 (例如: Data Pipeline 用 ZK 當作時間進度的控制器有線性一致的好處等等),之前考慮的往往都是『ZK 是一個很有名大家都在用的分散式調度系統』,並不會去思考背後達到了什麼的一致性或避免了什麼併發問題。
但看完最近幾章就發現要考慮的面向其實挺多的,最後又想到在讀 Cracking System Design 這類的文章,都會發現他們也都是把常見的 component 拿來討論大概都怎麼設計,並不會著墨到這麼底層的一致性問題 (自己以前在實做也是就拿常見的 Design Pattern 實做特定系統),所以就滿好奇實際上設計一個大型依賴系統是會真的考慮到這麼細緻的嗎 XDD
The text was updated successfully, but these errors were encountered: