阶段三,应用服务器集群-应用服务器负载告警,如何让应用服务器走向集群随着访问量的继续增加,单台应用服务器已经无法满足需求。在假设数据库服务器还没有遇到性能问题的时候,我们可以增加应用服务器,通过应用服务器集群将用户请求分流到各个服务器中,从而继续提升负载能力。此时多台应用服务器之间没有直接的交互,他们都是依赖数据库各自对外提供服务
这个架构的变化会带来几个问题1. 主从数据库之间的数据同步 ; 可以使用 mysql 自带的master-slave 方式实现主从复制2. 对应数据源的选择 ; 采用第三方数据库中间件,例如 mycat
阶段五,使用搜索引擎缓解读库的压力数据库做读库的话,尝尝对模糊查找效率不是特别好,像电商类的网站,搜索是非常核心的功能,即便是做了读写分离,这个问题也不能有效解决。那么这个时候就需要引入搜索引擎了使用搜索引擎能够大大提高我们的查询速度,但是同时也会带来一些附加的问题,比如维护索引的构建。
阶段六,引入缓存机制缓解数据库的压力随着访问量的持续增加,逐渐出现许多用户访问统一部分内容的情况,对于这些热点数据,没必要每次都从数据库去读取,我们可以使用缓存技术,比如 memcache、redis 来作为我们应用层的缓存;另外在某些场景下,比如我们对用户的某些IP的访问频率做限制,那这个放内存中又不合适,放数据库又太麻烦,这个时候可以使用Nosql 的方式比如 mongDB 来代替传统的关系型数据库
阶段七,数据库的水平/垂直拆分我们的网站演进的变化过程,交易、商品、用户的数据都还在同一个数据库中,尽管采取了增加缓存,读写分离的方式,但是随着数据库的压力持续增加,数据库的瓶颈仍然是个最大的问题。因此我们可以考虑对数据的垂直拆分和水平拆分垂直拆分:把数据库中不同业务数据拆分到不同的数据库
水平拆分:把同一个表中的数据拆分到两个甚至跟多的数据库中,水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈,这时可以采取讲表拆分到多个数据库中
那么服务拆分以后,各个服务之间如何进行远程通信呢?通过 RPC 技术,比较典型的有:webservice、hessian、http、RMI等等前期通过这些技术能够很好的解决各个服务之间通信问题,but,互联网的发展是持续的,所以架构的演变和优化还在持续。