关于即时通讯:im即时通讯开发技术100到1000万高并发的架构演进

50次阅读

共计 3278 个字符,预计需要花费 9 分钟才能阅读完成。

在介绍架构之前,为了防止局部读者对架构设计中的一些概念不理解,上面对几个最根底的概念进行介绍。

1)什么是分布式?

零碎中的多个模块在不同服务器上部署,即可称为分布式系统,如 Tomcat 和数据库别离部署在不同的服务器上,或两个雷同性能的 Tomcat 别离部署在不同服务器上。

2)什么是高可用?

零碎中局部节点生效时,其余节点可能接替它持续提供服务,则可认为零碎具备高可用性。

3)什么是集群?

一个特定畛域的软件部署在多台服务器上并作为一个整体提供一类服务,这个整体称为集群。

如 Zookeeper 中的 Master 和 Slave 别离部署在多台服务器上,独特组成一个整体提供集中配置服务。

在常见的集群中,客户端往往可能连贯任意一个节点取得服务,并且当集群中一个节点掉线时,其余节点往往可能主动的接替它持续提供服务,这时候阐明集群具备高可用性。

4)什么是负载平衡?

申请发送到零碎时,通过某些形式把申请平均散发到多个节点上,使零碎中每个节点可能平均的解决申请负载,则可认为零碎是负载平衡的。

5)什么是正向代理和反向代理?

零碎外部要拜访内部网络时,对立通过一个代理服务器把申请转发进来,在内部网络看来就是代理服务器发动的拜访,此时代理服务器实现的是正向代理;

当内部申请进入零碎时,代理服务器把该申请转发到零碎中的某台服务器上,对外部申请来说,与之交互的只有代理服务器,此时代理服务器实现的是反向代理。

简略来说,正向代理是代理服务器代替零碎外部来拜访内部网络的过程,反向代理是内部申请拜访零碎时通过代理服务器转发到外部服务器的过程。

以淘宝作为例子:在网站最后时,利用数量与用户数都较少,能够把 Tomcat 和数据库部署在同一台服务器上。浏览器往发动申请时,首先通过 DNS 服务器(域名零碎)把域名转换为理论 IP 地址 10.102.4.1,浏览器转而拜访该 IP 对应的 Tomcat。

架构瓶颈:随着用户数的增长,Tomcat 和数据库之间竞争资源,单机性能不足以撑持业务。

第一次演进:Tomcat 与数据库离开部署

Tomcat 和数据库别离独占服务器资源,显著进步两者各自性能。

架构瓶颈:随着用户数的增长,并发读写数据库成为瓶颈。

第二次演进:引入本地缓存和分布式缓存

在 Tomcat 同服务器上或同 JVM 中减少本地缓存,并在内部减少分布式缓存,缓存热门商品信息或热门商品的 html 页面等。通过缓存能把绝大多数申请在读写数据库前拦挡掉,大大降低数据库压力。其中波及的技术包含:应用 memcached 作为本地缓存,应用 Redis 作为分布式缓存,还会波及缓存一致性、缓存穿透 / 击穿、缓存雪崩、热点数据集中生效等问题。

架构瓶颈:缓存抗住了大部分的拜访申请,随着用户数的增长,并发压力次要落在单机的 Tomcat 上,响应逐步变慢。

第三次演进:引入反向代理实现负载平衡

在多台服务器上别离部署 Tomcat,应用反向代理软件(Nginx)把申请平均散发到每个 Tomcat 中。此处假如 Tomcat 最多反对 100 个并发,Nginx 最多反对 50000 个并发,那么实践上 Nginx 把申请散发到 500 个 Tomcat 上,就能抗住 50000 个并发。

其中波及的技术包含:Nginx、HAProxy,两者都是工作在网络第七层的反向代理软件,次要反对 http 协定,还会波及 session 共享、文件上传下载的问题。

架构瓶颈:反向代理使应用服务器可反对的并发量大大增加,但并发量的增长也意味着更多申请穿透到数据库,单机的数据库最终成为瓶颈。

第四次演进:数据库读写拆散

把数据库划分为读库和写库,读库能够有多个,通过同步机制把写库的数据同步到读库,对于须要查问最新写入数据场景,可通过在缓存中多写一份,通过缓存取得最新数据。其中波及的技术包含:Mycat,它是数据库中间件,可通过它来组织数据库的拆散读写和分库分表,客户端通过它来拜访上层数据库,还会波及数据同步,数据一致性的问题。即时通讯聊天软件开发能够征询蔚可云开发。

架构瓶颈:业务逐步变多,不同业务之间的访问量差距较大,不同业务间接竞争数据库,相互影响性能。

第五次演进:数据库按业务分库

把不同业务的数据保留到不同的数据库中,使业务之间的资源竞争升高,对于访问量大的业务,能够部署更多的服务器来撑持。这样同时导致跨业务的表无奈间接做关联剖析,须要通过其余路径来解决,但这不是本文探讨的重点,有趣味的能够自行搜寻解决方案。

架构瓶颈:随着用户数的增长,单机的写库会逐步会达到性能瓶颈。

第六次演进:把大表拆分为小表

比方针对评论数据,可依照商品 ID 进行 hash,路由到对应的表中存储;针对领取记录,可依照小时创立表,每个小时表持续拆分为小表,应用用户 ID 或记录编号来路由数据。只有实时操作的表数据量足够小,申请可能足够平均的散发到多台服务器上的小表,那数据库就能通过程度扩大的形式来进步性能。其中后面提到的 Mycat 也反对在大表拆分为小表状况下的访问控制。

这种做法显著的减少了数据库运维的难度,对 DBA 的要求较高。数据库设计到这种构造时,曾经能够称为分布式数据库,然而这只是一个逻辑的数据库整体,数据库里不同的组成部分是由不同的组件独自来实现的,如分库分表的治理和申请散发,由 Mycat 实现,SQL 的解析由单机的数据库实现,读写拆散可能由网关和音讯队列来实现,查问后果的汇总可能由数据库接口层来实现等等,这种架构其实是 MPP(大规模并行处理)架构的一类实现。

目前开源和商用都曾经有不少 MPP 数据库,开源中比拟风行的有 Greenplum、TiDB、Postgresql XC、HAWQ 等,商用的如南大通用的 GBase、睿帆科技的雪球 DB、华为的 LibrA 等等,不同的 MPP 数据库的侧重点也不一样,如 TiDB 更侧重于分布式 OLTP 场景,Greenplum 更侧重于分布式 OLAP 场景,这些 MPP 数据库根本都提供了相似 Postgresql、Oracle、MySQL 那样的 SQL 规范反对能力,能把一个查问解析为分布式的执行打算散发到每台机器上并行执行,最终由数据库自身汇总数据进行返回,也提供了诸如权限治理、分库分表、事务、数据正本等能力,并且大多可能反对 100 个节点以上的集群,大大降低了数据库运维的老本,并且使数据库也可能实现程度扩大。

架构瓶颈:数据库和 Tomcat 都可能程度扩大,可撑持的并发大幅提高,随着用户数的增长,最终单机的 Nginx 会成为瓶颈。

第七次演进:应用 LVS 或 F5 来使多个 Nginx 负载平衡

因为瓶颈在 Nginx,因而无奈通过两层的 Nginx 来实现多个 Nginx 的负载平衡。图中的 LVS 和 F5 是工作在网络第四层的负载平衡解决方案,其中 LVS 是软件,运行在操作系统内核态,可对 TCP 申请或更高层级的网络协议进行转发,因而反对的协定更丰盛,并且性能也远高于 Nginx,可假如单机的 LVS 可反对几十万个并发的申请转发;F5 是一种负载平衡硬件,与 LVS 提供的能力相似,性能比 LVS 更高,但价格昂贵。因为 LVS 是单机版的软件,若 LVS 所在服务器宕机则会导致整个后端系统都无法访问,因而须要有备用节点。可应用 keepalived 软件模拟出虚构 IP,而后把虚构 IP 绑定到多台 LVS 服务器上,浏览器拜访虚构 IP 时,会被路由器重定向到实在的 LVS 服务器,当主 LVS 服务器宕机时,keepalived 软件会自动更新路由器中的路由表,把虚构 IP 重定向到另外一台失常的 LVS 服务器,从而达到 LVS 服务器高可用的成果。

此处须要留神的是,上图中从 Nginx 层到 Tomcat 层这样画并不代表全副 Nginx 都转发申请到全副的 Tomcat,在理论应用时,可能会是几个 Nginx 上面接一部分的 Tomcat,这些 Nginx 之间通过 keepalived 实现高可用,其余的 Nginx 接另外的 Tomcat,这样可接入的 Tomcat 数量就能成倍的减少。

架构瓶颈:因为 LVS 也是单机的,随着并发数增长到几十万时,LVS 服务器最终会达到瓶颈,此时用户数达到千万甚至上亿级别,用户散布在不同的地区,与服务器机房间隔不同,导致了拜访的提早会显著不同。

正文完
 0