『互联网架构』软件架构-分布式之大型网站的演变过程(28)

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

单体应用

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:技术的选型,一定了解业务,才能知道他的解决方案。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-分布式之大型网站的演变过程(28)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注