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小时法则后，这周下定决心，定下目标三天要把第三章看完，最终完成了。选择少一点的目标，并设置一个期限，有利于目标的完成。

原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。

如果本文对你有帮助，麻烦顺手点个赞吧，谢谢

推荐阅读：

ARTS挑战打卡的100天，我学到了这些