ARTS挑战打卡第十六周
Algorithm-一周至少一道算法题
Review-阅读并点评至少一篇英文技术文章
Tip-学习至少一个技术技巧，总结和归纳在日常工作中所遇到的知识点
Share-分享一篇有观点和思考的技术文章
01-Algorthm
———————
https://leetcode.com/problems/same-tree
判断两个树是否相同，思路很简单，先序遍历，判断完根结点再递归判断左右子节点。
02-Review
——————
阅读Nginx官网文章：
https://www.nginx.com/blog/introduction-to-microservices/
介绍了单体服务的缺点，推荐使用微服务。
单体服务的缺点：
1、强耦合
2、难维护
3、启动慢
拆分成微服务有利于维护和部署，优点是很明显的，但是没有银弹，微服务也会带来困扰，缺点如下：
1、多小的粒度才是合适的微服务？
2、分布式系统情况下，服务间的通信会带来延迟
3、增加测试复杂度，有时需要同时启动多个微服务
微服务还是推荐使用的，优点大于缺点，可以使用其他技术去解决它的缺点，享受它带来的优点。
03-Tip
——————
最近在使用pulsar，据说可靠性比NSQ强，结合使用心得和目前的理解认知经验，个人认为分布式消息队列中丢消息分为3种：
1.发送前
这种情况，中间件无法保证，使用方需要在发送前记录下消息，发送成功后，自行标记消息已成功发送，如果消息失败，使用方自己做重试，这就保证了发之前不丢了。这种情况下在数据一定不能丢且需要很高的一致性的情况下，需要在发送前记录下消息
2.发送到中间件
pulsar这边是落盘后，内部做ACK，副本ACK后才给使用方回复ACK。
3.发送后
消费者消费成功后放回ACK，提交消息就行了。下游一定要做好幂等性，避免重复消费带来的数据错误。
如果这三步都做了，也几乎接近百分百不丢消息了，至少可以做到99.999%吧。
04-Share
—————
分享一个摆脱拖延症的方法-72小时法则
如果想做一件事情，那么就为它设置一个期限，72小时。因为一件事情，如果你72小时内都没有去完成，那么很有可能你接下来几年甚至一辈子都不会去完成了。
手上事情太多，那就不断精简，选出一件最想做的事情，下定决心，在72小时内完成，否则就换另一件事情。
最近这个方法有短暂的解决了我的拖延症，看完了《Java并发编程实战》前三章，本来拖了好几个月了，因为一直在忙着学其他东西。看了这个72小时法则后，这周下定决心，定下目标三天要把第三章看完，最终完成了。选择少一点的目标，并设置一个期限，有利于目标的完成。
原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。
如果本文对你有帮助，麻烦顺手点个赞吧，谢谢
推荐阅读：