1. Algorithm 每周一道算法题

本周算法题为最小栈

本题有趣的点在于可以利用差值法减少一个栈的空间使用

2. Review 阅读一篇英文文章

本周没有学习英文文章

3. Techniques/Tips 分享一个小技巧

最近学习了公司内部毕玄的异地多活公开课，收获很多，不是所有业务都适合做异地多活，并且异地多活是个系统性的项目，问题难点在于时延带来的同步问题，解决办法是尽可能将请求收敛在同一机房，也就是阿里说的单元化 SET，单元化的重点是要对服务的机器打上标签，相同标签容器部署在同一机房，这样能将一次请求所有链路收敛在同一机房，但这又要求所有项目涉及的所有中间件都需要能根据 SET 标签进行路由，因此异地多活是一个系统性的项目，要推动极其困难，不仅有业务难度，更多的是沟通协调难度，并且对有些业务是不适合做异地多活的，比如商品库存等业务，对于一致性要求极高，不适合做异地多活，但是对于搜索、视频、即时通讯等做起来却简单很多，因为这些业务对一致性要求并不是非常高，可用性 > 一致性，就像阿里，买家侧是做了异地多活的，但是商品侧却没有，因为库存对一致性要求很高，还有我们前面看到的阿里云也没做异地多活，阿里云做异地多活的难点在于阿里云上的业务没有异地多活，你总不能要求买你服务器的用户都必须做异地多活吧，因此阿里云做异地多活基本是不可能完成的任务，以前无知，感觉阿里云好蠢，这都满足不了还做啥云服务商，了解后才知道阿里云的难处。

4. Share 分享一个观点

工作中需要多沟通，切忌个人死钻问题，很多问题其实沟通好了很简单，比如最近在对接 1688，需要在聚石塔购买服务器做请求转发，调研后出了两个方案，其中一个方案有单点问题，但预算能省 87%，并且 1688 有接口能事后拉取失败消息进行消费，因此我们很自然的就认为一定选低成本方案，尽管方案本身要复杂很多，因此就开始研究文档、接口，做方案设计，就剩编码了，然后我们跟我们的下游以及产品聊了下，结果他们对成本根本不关心，因为方案一一年 16000，方案二一年 2600.尽管方案二能节省 87%，但是对他们来说一年 16000 根本不算什么，要的是稳定，不出错，结果我们才发现我们很多工作都白做了，尽早沟通其实能省下很多时间，并且在项目本身就很紧急的情况下更要多沟通，降低无效成本