江苏龙网

  1. 首页 > 人文 > >

数据库：阿里巴巴为什么能够抗住90秒100亿？看完我哭了。( 二 )


Nginx反向代理
第四次演变 ， 数据库读写分离 ， 把数据库划分为读库和写库 ， 读库可以有多个 ， 通过同步机制把写库的数据同步到读库 ， 对于需要查询最新写入数据场景 ， 可通过在缓存中多写一份 ， 通过缓存获得最新数据 。 其中涉及的技术包括：Mycat ， 它是数据库中间件 ， 可通过它来组织数据库的分离读写和分库分表 ， 客户端通过它来访问下层数据库 ， 还会涉及数据同步 ， 数据一致性的问题 。 架构瓶颈：业务逐渐变多 ， 不同业务之间的访问量差距较大 ， 不同业务直接竞争数据库 ， 相互影响性能 。
数据库读写分离
第五次演变 ， 数据库按业务分库把不同业务的数据保存到不同的数据库中 ， 使业务之间的资源竞争降低 ， 对于访问量大的业务 ， 可以部署更多的服务器来支撑 。 这样同时导致跨业务的表无法直接做关联分析 ， 需要通过其他途径来解决 ， 但这不是本文讨论的重点 ， 有兴趣的可以自行搜索解决方案 。 架构瓶颈：随着用户数的增长 ， 单机的写库会逐渐会达到性能瓶颈 。
按业务分库
第六次演变 ， 把大表拆分为小表比如针对评论数据 ， 可按照商品ID进行hash ， 路由到对应的表中存储；针对支付记录 ， 可按照小时创建表 ， 每个小时表继续拆分为小表 ， 使用用户ID或记录编号来路由数据 。 只要实时操作的表数据量足够小 ， 请求能够足够均匀的分发到多台服务器上的小表 ， 那数据库就能通过水平扩展的方式来提高性能 。 Mysql也支持在大表拆分为小表情况下的访问控制 。 数据库和Tomcat都能够水平扩展 ， 可支撑的并发大幅提高 ， 随着用户数的增长 ， 最终单机的Nginx会成为瓶颈
大表的拆分
第七次演变使用LVS或F5来使多个Nginx负载均衡图中的LVS和F5是工作在网络第四层的负载均衡解决方案 ， 其中LVS是软件 ， 运行在操作系统内核态 ， 可对TCP请求或更高层级的网络协议进行转发 ， 因此支持的协议更丰富 ， 并且性能也远高于Nginx ， 可假设单机的LVS可支持几十万个并发的请求转发；F5是一种负载均衡硬件 ， 与LVS提供的能力类似 ， 性能比LVS更高 ， 但价格昂贵 。 由于LVS是单机版的软件 ， 若LVS所在服务器宕机则会导致整个后端系统都无法访问 ， 因此需要有备用节点 。 可使用keepalived软件模拟出虚拟IP ， 然后把虚拟IP绑定到多台LVS服务器上 ， 浏览器访问虚拟IP时 ， 会被路由器重定向到真实的LVS服务器当主LVS服务器宕机时 ， keepalived软件会自动更新路由器中的路由表 ， 把虚拟IP重定向到另外一台正常的LVS服务器 ， 从而达到LVS服务器高可用的效果 。
LVS/F5负载均衡
第八次演变 ， 通过DNS轮询实现机房间的负载均衡在DNS服务器中可配置一个域名对应多个IP地址 ， 每个IP地址对应到不同的机房里的虚拟IP 。 当用户访问淘宝时 ， DNS服务器会使用轮询策略或其他策略 ， 来选择某个IP供用户访问 。 此方式能实现机房间的负载均衡至此 ， 系统可做到机房级别的水平扩展 ， 千万级到亿级的并发量都可通过增加机房来解决 ， 系统入口处的请求并发量不再是问题 。 架构瓶颈：随着数据的丰富程度和业务的发展 ， 检索、分析等需求越来越丰富 ， 单单依靠数据库无法解决如此丰富的需求 。
轮询
第九次演变 ， 引入NoSQL数据库和搜索引擎等技术 ， 当数据库中的数据多到一定规模时 ， 数据库就不适用于复杂的查询了 ， 往往只能满足普通查询的场景 。 对于统计报表场景 ， 在数据量大时不一定能跑出结果 ， 而且在跑复杂查询时会导致其他查询变慢对于全文检索、可变数据结构等场景 ， 数据库天生不适用 。 因此需要针对特定的场景 ， 引入合适的解决方案 。 如对于海量文件存储 ， 可通过分布式文件系统HDFS解决 ， 对于key value类型的数据 ， 可通过HBase和Redis等方案解决对于全文检索场景 ， 可通过搜索引擎如ElasticSearch解决 ， 对于多维分析场景 ， 可通过Kylin或Druid等方案解决 。 架构瓶颈：引入更多组件解决了丰富的需求 ， 业务维度能够极大扩充 ， 随之而来的是一个应用中包含了太多的业务代码 ， 业务的升级迭代变得困难 。


推荐阅读


上一篇：【手机中国】小米1.5亿像素拍照手机曝光！预计第四季度全球首发

下一篇：#蓝果网络#门店微信小程序与订阅号怎么衔接？