ARTS挑战打卡第二周

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