原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『互联网架构』软件架构-分布式之大型网站的演变过程（28）
项目都是从单一的应用，到分布式应用，到流式的基栈，这样的思想。
单体应用
app应用，db数据库，server服务都在同一台机器上
集群应用
随着业务量的增大，一台服务器，需要进行拆分到3台服务器。
server服务和app在一台机器上。2台应用的，一台数据库的。
在真正的开发过程中，由一个应用变成多个了会发生什么样的问题？
1.session集群问题
2.数据一致性问题
3.数据瓶颈（一旦流量上来了，虽然应用做了集群，但是数据库没有做集群，还是一个主库），这时候要考虑主从数据库。
N多个模板一直操作同一个数据库，数据库需要负载如何负载，将业务进行拆分，不同的业务访问自己的数据库。降低主库的压力。
互联网的特性就是读多写少。
如果双11了，交易额大的话，其实交易的读写库压力就很大。采用的方案是：分库分表：垂直分库，水平分表。模块的专库专用，就是一种垂直的分库。分表是根据关键的字段orderId，userId将信息存储到指定的表中。
水平分表的策略（hash，range，list）
- range 和 list 要进行预估扩容很麻烦
- hash 热点数据进行分散，分布均衡，扩容也比较麻烦。
前端
- 用户如果使用userId比较多
- 数据一致性要求比较高
- 查询我的订单（userId查）
- userId，时间查询条件
后端
- 内部数据要求不太高
- 业务复杂
- 有通过非userId来进行查询，当天所有的下单总数，下单的人数。
- 消息中间件 和 es cluster（canal异构）整理成后端需要的。
- 不查询数据库，通过es来进行查询
- es 获取数据库的同步分：延时，实时，维度，增量，全量。其实就是读binlog的日志。
- 大的变小的，不断的拆分， 不断的合并
- 最后可能到后台就是一个漏洞的锥子形状，越往后面越少，前面能过滤的都过滤掉了。
涉及到技术点
java，分库分表，redis缓存，搜索引擎，RPC远程调用，所有大型分布式都涉及到并发编程这一点。
PS：技术的选型，一定了解业务，才能知道他的解决方案。
