项目都是从单一的应用，到分布式应用，到流式的基栈，这样的思想。

单体应用

app应用，db数据库，server服务都在同一台机器上

集群应用

随着业务量的增大，一台服务器，需要进行拆分到3台服务器。
server服务和app在一台机器上。2台应用的，一台数据库的。

在真正的开发过程中，由一个应用变成多个了会发生什么样的问题？

1.session集群问题
2.数据一致性问题
3.数据瓶颈（一旦流量上来了，虽然应用做了集群，但是数据库没有做集群，还是一个主库），这时候要考虑主从数据库。

N多个模板一直操作同一个数据库，数据库需要负载如何负载，将业务进行拆分，不同的业务访问自己的数据库。降低主库的压力。
互联网的特性就是读多写少。

如果双11了，交易额大的话，其实交易的读写库压力就很大。采用的方案是：分库分表：垂直分库，水平分表。模块的专库专用，就是一种垂直的分库。分表是根据关键的字段orderId，userId将信息存储到指定的表中。

水平分表的策略（hash，range，list）

1. range 和 list 要进行预估扩容很麻烦
2. hash 热点数据进行分散，分布均衡，扩容也比较麻烦。

前端

1. 用户如果使用userId比较多
2. 数据一致性要求比较高
3. 查询我的订单（userId查）
4. userId，时间查询条件

后端

1. 内部数据要求不太高
2. 业务复杂
3. 有通过非userId来进行查询，当天所有的下单总数，下单的人数。
4. 消息中间件 和 es cluster（canal异构）整理成后端需要的。
5. 不查询数据库，通过es来进行查询
6. es 获取数据库的同步分：延时，实时，维度，增量，全量。其实就是读binlog的日志。
7. 大的变小的，不断的拆分， 不断的合并
8. 最后可能到后台就是一个漏洞的锥子形状，越往后面越少，前面能过滤的都过滤掉了。

涉及到技术点

java，分库分表，redis缓存，搜索引擎，RPC远程调用，所有大型分布式都涉及到并发编程这一点。

PS：技术的选型，一定了解业务，才能知道他的解决方案。