ARTS挑戰
Algorithm-一週至少一道算法題
Review-閱讀並點評至少一篇英文技術文章
Tip-學習至少一個技術技巧，總結和歸納在日常工作中所遇到的知識點
Share-分享一篇有觀點和思考的技術文章
第二週：200518-200524
Algorithm
判斷二叉樹是否全部值一致 - https://leetcode.com/problems/univalued-binary-tree/
思路：遞歸判斷（DFS）
1、如果節點爲空，返回true
2、否則判斷節點與左/右節點，如果不一致，返回false
3、遞歸判斷左右子樹
Review
How to do distributed locking
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
文章介紹瞭如何設計一個分佈式鎖。
使用鎖的原因，就是爲了保證當多個節點嘗試做同一件事時（比如寫數據、運算、第三方調用，等等），只有一個節點能真正執行。
從更高維度來看，在分佈式系統中，使用鎖的原因有兩個：
Efficiency-提高效率，避免同一件事情執行兩次，也可以理解爲一種冪等的用途。
Correctness-正確性，使用鎖來避免多個併發進程互相影響污染系統的狀態。（比如，如果鎖失敗了，就會導致文件損壞、數據丟失、數據不一致性等）
如果在使用鎖的時候，第一個進程由於某種原因（GC）暫停了，就會導致被另一個進程搶佔到鎖，最終出現數據污染。解決方案就是使用fencing token，可理解爲一個遞增的數據版本號，寫入時只有擁有最新的token才能成功寫入。
另一個可能導致鎖混亂（兩個進程獲得鎖）的情況就是操作系統時鐘混亂。
某些分佈式鎖的實現是有假設前提存在才能成功，對於RedLock而言，有以下假設：
有界限的網絡延遲
有界限的進程暫停
有界限的時鐘錯誤
RedLock假設以上這些都是很小几率存在的，如果機率變大時，分佈式鎖算法就失敗了。
具體情況具體分析，如果只是爲了使用冪等，可接受部分正確性的失敗，那麼是沒問題的；但是如果系統要求正確性較強，那麼就必須加上fencing token保證數據正確寫入。
在開發者自己的設計中，很容易會假設以上場景發生的概率很小，要注意這些假設的前提。在使用其他框架或者sdk時，也要看看第三方的設計是否存在某些假設的前提，如果這些假設不成立，應該怎麼避免。
How to read and understand a scientific paper: a guide for non-scientists
https://violentmetaphors.com/2013/08/25/how-to-read-and-understand-a-scientific-paper-2/
先讀簡介
記錄不懂的單詞
記住最大的疑問—整一篇論文在嘗試解答什麼問題？
畫個圖（腦圖？），嘗試捋清作者的思路
Tip
如果功能來不及做後臺，那就做一個每天核心數據的通知，比如企業微信、郵件。可以避免PM每天找你跑數，也有利於自己觀察業務數據。
Share
blog-理解Java8中的時間API