项目都是从单一的应用，到分布式应用，到流式的基栈，这样的思想。
单体应用（一）
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：技术的选型，一定了解业务，才能知道他的解决方案。
点击
