![[总结]MySQL主从读写分离经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-medium-empty.png)
[总结]MySQL主从读写分离经验
数据库读写分离的这些坑，让我一脸懵逼！ 「由于数据库同步存在延时，这就导致数据同步的这段时间，主从数据将会不一致，从库无法查询到最新的数据。」 最优解：缓存路由大法
Mobabel Blog
[总结]全链路分布式追踪系统经验
微服务中台技术解析之全链路分布式追踪系统实践 用了3年CAT，这次我想选择SkyWalking，老板反手就是一个赞！ 全链路监控神器Skywalking，就是这么秀！
[转]40张图看懂SkyWalking分布式追踪系统原理及实践
40张图看懂SkyWalking分布式追踪系统原理及实践 不论是 CPU，内存，还是响应时间，使用 SkyWalking 带来的性能损耗几乎可以忽略不计。 接下来我们再来看 SkyWalking 与另一款业界比较知名的分布式追踪工具 Zipkin, Pinpoint 的对比（在采样率为 1 秒 1 个，线程数 500，请求总数为 5000 的情况下做的对比）,可以看到在关键的响应时间上， Zipkin（117ms）,PinPoint（201ms）远逊色于 SkyWalking（22ms）
[汇总]分布式ID经验
美团（Leaf）分布式ID生成器 ULID – 一种比UUID更好的方案 为什么MySQL不推荐使用uuid或者雪花id作为主键？ 时间占用量总体可以打出的效率排名为：auto_key>random_key>uuid 那么使用自增的id就完全没有坏处了吗？并不是，自增id也会存在以下几点问题： ①别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息，很容易分析出你的经营情况 ②对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争 ③Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失 我在项目里用雪花算法搞了唯一ID生成，结果上线就引发了故障 我们猜测是不是服务器上的时钟不同步后，又自动进行同步了，前后时间不一致。
[转]架构师必须知道的架构设计原则
如果一个技术已经存在 2 年，比如现在很火的前端技术 React 和 Vue 等，那么我能预估这个技术大致还有 2 年的生命期，再久就不确定了；如果一个架构或设计原则已经存在 15 年，例如单一职责和依赖倒置原则，我可以预期它还有 15 年甚至更久的生命期。原则是比具体技术更抽象，更接近事物本质，也更经得起时间考验的东西。这些原则沉淀在架构师的脑海中，最终内化成他的 mindset，以潜意识方式影响和指导他的架构和设计工作。
[转]为什么不建议把数据库部署在Docker容器内？
近2年Docker非常的火热，各位开发者恨不得把所有的应用、软件都部署在Docker容器中，但是您确定也要把数据库也部署的容器中吗？ 这个问题不是子虚乌有，因为在网上能够找到很多各种操作手册和视频教程，小编整理了一些数据库不适合容器化的原因供大家参考，同时也希望大家在使用时能够谨慎一点。 目前为止将数据库容器化是非常不合理的，但是容器化的优点相信各位开发者都尝到了甜头，希望随着技术的发展能够更加完美的解决方案出现。
[转]HttpClient 连接池设置引发的一次雪崩
1. 一. 事件背景 我最近运维了一个网上的实时接口服务，最近经常出现Address already in use (Bind failed)的问题。很明显是一个端口绑定冲突的问题，于是大概排查了一下当前系统的网络连接情况和端口使用情况，发现是有大量time_wait的连接一直占用着端口没释放，导致端口被占满（最高的时候6w+个），因此HttpClient建立连接的时候会出现申请端口冲突的情况。
[汇总]单体转微服务
Self-contained System Each SCS is an autonomous web application. For the SCS’s domain, all data, the logic to process that data and all code to render the web interface is contained within the SCS....
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
