微服务，顾名思义，就是将我们程序拆分为最小化单元来提供服务。在一体化系统中，各个微服务也是不可能独立存在的，那么微服务之间涉及到的数据依赖问题，应该怎么处理呢？

最终一致性和实时一致性是什么？在日常业务中我们应该怎么设计？怎么取舍？

微服务架构有哪些痛？面对这些问题你是怎么解决的呢？看看这里的思路，是不是能解决你的某些问题。

微服务下如何保证系统稳定性，避免底层服务出错导致所有服务不可用，试试这个方案！

微服务架构之痛，你经历了多少？ 看看这里的方案能否解你燃眉之急~

你的项目真的适合微服务架构吗？微服务架构有哪些痛呢？我们一起来看看吧！

如何保障服务器承受住亿级流量？你知道哪几种方式吗？对于限流，你知道有几种算法吗？收藏下，加深记忆。

今天讨论的内容是冷热分离，也许概念并不陌生，对其使用场景也比较熟悉，但涉及锁的内容时仍然需要认真思考，这部分内容在我们实际开发中的“坑”还是不少的。业务场景一曾经经历过供应链相关的架构优化，当时平台上有一个订单功能，里面的主表有几千万数据量，加上关联表，数据量达到上亿。这么庞大的数据量，让平台的查询订单变得格外迟缓，查询一次都要二三十秒，而且多点击几次就会出现宕机。比如业务员多次查询时，数据库的CPU会立马狂飙，服务器线程也降不下来。当时，我们尝试了优化表结构、业务代码、索引、SQL语句等.

上一篇聊到过，冷热分离解决方案的性价比高，但它并不是一个最优的方案，仍然存在诸多不足，比如：查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住，我们如果想把这些问题一一解决掉，可以用另外一种解决方案——查询分离。（注意：查询分离与读写分离还是有区别的。）业务场景二某SaaS客服系统，系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。面对如此庞大的数据量，跟前面的冷热分离一样，每次客户查询数据时几十秒才能返回..

在第二篇文章中说到，查询分离中存在三大不足，其中一个不足就是：当主数据量越来越大，写操作缓慢，遇到这个问题我们该如何解决呢？为此，这篇文章我们主要围绕这个问题来讨论，拆分存储如何进行技术选型？分库分表的实现思路是什么？分库分表存在哪些不足？一、业务场景三为了便于理解，我们通过一个业务场景来入手。有一个电商系统架构优化工作，该系统中包含用户和订单2个主要实体，每个实体涵盖数据量如下表所示：实体数据量增长趋势用户千万级每日10万订单亿级每日百万级，后续可能千万级