负载均衡方案; 2、如何保持状态信息的同步,例如用户 session 等,这个时候会考虑的方 案有写入数据库、写入存储、cookie 或同步 session 信息等机制等; 3、如何保持数据缓存信息的同步,例如之前缓存的用户数据等,这个时候 通常会考虑的机制有缓存同步或分布式缓存; 4、如何让上传文件这些类似的功能继续正常,这个时候通常会考虑的机制 是使用共享文件系统或存储等; 在解决了这些问题后,终于是把 webserver 增加为了两台,系统终于是又恢 复到了以
往的速度。 看看这一步完成后系统的图示:
增加 webserver 这一步涉及到了这些知识体系:
负载均衡技术(包括但不限于硬件负载均衡、
软件负载均衡、 负载算法、 linux 转发协议、所选用的技术的实现细节等)、主备技术(包括但不限于 ARP 欺骗、
linux heart-beat 等)、状态信息或缓存同步技术(包括但不限于 Cookie 技术、 UDP 协议、状态信息广播、所选用的缓存同步技术的实现细节等)、共 享文件技 术(包括但不限于 NFS 等)、存储技术(包括但不限于存储设备等)。 架构演变第六步:分库 享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了, 这次又是什么状况呢, 经过查找, 发现数据库写入、 更新的这些操作的部分数 据 库连接的 资源竞争非常激烈,导致了系统变慢,这下怎么办呢,此时可选的方 案有数据库集群和分库策略,集群方面像有些数据库支持的并不是很好,因此分 库会成为比较普 遍 的策略,分库也就意味着要对原有
程序进行修改,一通修改 实现分库后,不错,目标达到了,系统恢复甚至速度比以前还快了。 看看这一步完成后系统的图示:
分库 这一步涉及到了这些知识体系: 这一步更多的是需要从业务上做合理的划分,以实现分库,具体技术细节上 没有其他的要求; 但同时随着数据量的增大和分库的进行,在数据库的
设计、调优以及维护上 需要做的更好,因此对这些方面的技术还是提出了很高的要求的。 架构演变第七步:分表、DAL 和分布式缓存
随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后
查询仍 然会有些慢, 于是按照分库的思想开始做分表的工作, 当然, 这不可避免的会 需 要对程序进行一些修改, 也许在这个时候就会发现应用自己要关心分库分表的规 则等,还是有些复杂的,于是萌生能否增加一个通用的框架来实现分库分表的数 据 访问,这个在 ebay 的架构中对应的就是 DAL,这个演变的过程相对而言需要 花费较长的时间,当然,也有可能这个通用的框架会等到分表做完后才开始做, 同 时, 在这个阶段可能会发现之前的缓存同步方案出现问题, 因为数据量太大, 导致现在不太可能将缓存存在本地,然后同步的方式,需要采用分布式缓存
方案 了,于 是,又是一通考察和折磨,终于是将大量的数据缓存转移到分布式缓存 上了。 看看这一步完成后系统的图示:
分表、DAL 和分布式缓存 这一步涉及到了这些知识体系:
分表更多的同样是业务上的划分,技术上涉及到的会有动态 hash 算法、 consistent hash 算法等; DAL 涉及到比较多的复杂技术,例如数据库连接的管理(超时、
异常)、数据 库操作的控制(超时、异常)、分库分表规则的封装等; 架构演变第八步:增加更多的 webserver 在做完分库分表这些
工作后,数据库上的压力已经降到比较低了,又开始过 着每天看着访问量暴增的幸福生活了, 突然有一天, 发现系统的访问又开始有 变 慢的趋势 了, 这个时候首先查看数据库, 压力一切正常, 之后查看 webserver, 发现 apache 阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来 是请求数太高导致需要排队等待,响应速度变慢,这还好办,一般来说,这个时 候也会有些钱了,于是添加一些 webserver 服务器,在这个添加 webserver 服 务器的过