技术选型(一)分布式缓存、消息队列和负载均衡
5.1 分布式缓存架构:架构原理与使用中的注意事项
什么是缓存
缓存:存储在计算机上的一个原始数据复制集,以便于访问
缓存是介于数据访问者和数据源之间的一种高速存储,当数据需要多次读取的时候,用于加快读取的速度。
缓存 Cache 和缓冲 Buffer 的分别?
缓存无处不在
计算机体系结构
CPU 缓存 L1 L2
操作系统缓存
数据库缓存
JVM 编译缓存
分布式系统
CDN 缓存
代理与反向代理
前端缓存
应用程序缓存
分布式对象缓存
各种介质数据访问延迟
Memory: 100 ns
SSD: 100,000 ns
Hard Disk (non SSD): 10,000,000 ns
Sequence read 1 MB data from network: 10,000,000 ns
Sequence read 1 MB data from hard disk: 30,000,000 ns
Network transport data through Atlantic: 150,000,000 ns
缓存的关键指标
缓存命中率:缓存是否有效依赖于能多少次重用同一个缓存相应业务请求
缓存键集合大小:生成唯一键越多,重用的机会越小。键数量越少,缓存的效率越高
缓存可使用内存空间:物理上能缓存的对象越多,缓存命中率越高
缓存对象生存空间:缓存对象生存时间 TTL(Time To live),对象缓存时间越长,重用可能性越高
5.2 常见的缓存实现形式
代理缓存:用户端,用户上网服务的一部分
反向代理缓存:数据中心的代理服务器
多层反向代理缓存
内容分发网络 CDN:
CDN 同时配置静态文件和动态内容:CloudFront
Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services. CloudFront works seamlessly with services including AWS Shield for DDoS mitigation, Amazon S3, Elastic Load Balancing or Amazon EC2 as origins for your applications, and Lambda@Edge to run custom code closer to customers’ users and to customize the user experience. Lastly, if you use AWS origins such as Amazon S3, Amazon EC2 or Elastic Load Balancing, you don’t pay for any data transferred between these services and CloudFront.
通读缓存 read-through:客户端连接的是通读缓存,而不是生成响应的原始服务器,包括代理缓存、反向代理缓存、内容分发网络 CDN
旁路缓存 cache-aside:对象缓存,应用代码询问对象缓存需要的对象是否存在
浏览器对象缓存
本地对象缓存:
对象缓存在应用程序内存
本地对象构建分布式集群
jBoss Cache,每台服务器上缓存的内容一样,缓存数据更新占据了宝贵的带宽
远程分布式对象缓存
Memchached 分布式对象缓存
share nothing 架构
Memchached 分布式缓存访问模型
5.3 分布式对象缓存一致性 Hash 算法
可能存在问题
Hash 存储、访问不均衡,两个节点有可能放得很近(随机放置)
增加节点之后,只能影响附近的一个节点,而不是分担所有节点的压力
基于虚拟节点的一致性 Hash 算法
缓存为什么能提升性能
内存的访问速度比硬盘快(并不是所有的缓存都在内存上)
存储数据的最终结果
降低 I/O 设备负载压力
缓存的优点:技术简单、性能提升明显、应用场景丰富
不适合使用缓存的场景
频繁修改的数据:读写比例在 2:1 以上,缓存才有意义
没有热点的访问:
缓存使用注意事项
数据不一致与脏读:缓存失效时间
缓存雪崩:数据库习惯了有缓存的日子,当缓存服务崩溃时,数据库因无法承受访问压力而宕机,进而导致整个网站不可用
缓存预热:warm up
缓存穿透:不恰当的业务或者恶意攻击持续高并发请求不存在的数据。将不存在的数据也缓存起来( value 值为 null),并设定一个较短的失效时间
Redis VS Memcached
Redis 支持复杂的数据结构
Redis 支持多路复用异步 I/O 高性能
Redis 支持主从复制高可用
Redis 原生集群与 share nothing 集群模式
5.4 消息队列:如何避免系统故障传递?
同步调用 vs. 异步调用
有回调的异步调用
多次异步调用,不阻塞应用线程
消息队列构建异步调用架构
消费生产者、消息队列、消息消费者
点对点模型
发布订阅模型
消息队列的优点
异步处理,提升性能
更好的伸缩性
削峰填谷
失败隔离和自我修复
解耦
事件驱动架构 EDA
事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言,事件的捕获、通信、处理和持久保留是解决方案的核心结构。这和传统的请求驱动模型有很大不同。
许多现代应用都采用了事件驱动设计。事件驱动应用可以用任何一种编程语言来创建,因为事件驱动本身是一种编程方法,而不是一种编程语言。事件驱动架构可以最大程度减少耦合度,因此是现代化分布式应用架构的理想之选。
事件驱动架构采用松散耦合方式,因为事件发起者并不知道哪个事件使用者在监听事件,而且事件也不知道其所产生的后续结果。
什么是事件
事件是指系统硬件或软件的状态出现任何重大改变。事件与事件通知不同,后者是指系统发送的消息或通知,用于告知系统的其他部分有相应的事件发生。
而事件的来源可以是内部或外部输入。事件可以来自用户(例如点击鼠标或按键)、外部源(例如传感器输出)或系统(例如加载程序)。
事件驱动架构的工作原理
事件驱动架构由事件发起者和事件使用者组成。事件的发起者会检测或感知事件,并以消息的形式来表示事件。它并不知道事件的使用者或事件引起的结果。
检测到事件后,系统会通过事件通道从事件发起者传输给事件使用者,而事件处理平台则会在该通道中以异步方式处理事件。事件发生时,需要通知事件使用者。他们可能会处理事件,也可能只是受事件的影响。
事件处理平台将对事件做出正确响应,并将活动下发给相应的事件使用者。通过这种下发活动,我们就可以看到事件的结果。
Apache Kafka 是一种分布式数据流平台,也是事件处理的常见之选。它可以实时进行事件流的发布、订阅、存储和处理。Apache Kafka 支持需要高吞吐量和可扩展性的用例,同时,通过最大程度减少某些应用中对数据共享的点对点集成需求,它可以将延迟降至毫秒级。
除此之外,还有其他一些中间件事件管理器也可用作事件处理平台。
事件驱动架构模型
事件驱动架构可以基于发布/订阅模型或事件流模型。
发布/订阅模型
这是一种基于事件流订阅的消息传递基础架构。对于该模型而言,在事件发生或公布之后,系统会将相应的消息发送给需要通知的订阅用户。
事件流模型
借助事件流模型,事件将被写入日志。事件使用者无需订阅事件流。相反,它们可以从流的任何部分读取并随时加入流。
事件流有几种不同的类型:
事件流处理使用诸如 Apache Kafka 等数据流平台来提取事件并处理或转换事件流。事件流处理可用于检测事件流中有用的模式。
简单事件处理是指事件立即在事件使用者中触发操作。
复杂事件处理则需要事件使用者处理一系列事件以检测模式。
事件驱动型构的优势
事件驱动架构可为企业提供一个灵活的系统,能够适应变化并实时做出决策。借助实时态势感知功能,您可以利用反映系统当前状态的所有可用数据,来做出业务决策(无论是人工还是自动)。
参考链接
主要 MQ 产品比较
RabbitMQ:性能好、社区活跃;Erlang 开发,不便于二次开发和维护
ActiveMQ:跨平台,Java 开发
RocketMQ:阿里开源,Java 开发,国际性不够好
Kafka:LinkedIn 出品,Scala 出发,分布式场景,伸缩性比较好
可以查一下 Google Trends
5.5 负载均衡架构:如何用十行代码写一个负载均衡服务器?
负载均衡架构
HTTP 重定向负载均衡
DNS 负载均衡
反向代理负载均衡
IP 负载均衡
数据链路层负载均衡
负载均衡算法
轮询:适用于所有服务器硬件相同的场景
加权轮询:根据服务器的硬件性能,高性能服务器分配更多请求
随机:简单实用,好的随机数本身就很均衡
最少连接:最符合负载均衡定义的算法
源地址散列:一个来源的请求总在同一个服务器上处理,会话粘滞
应用服务器集群的 Session 管理
Session 复制
Session 绑定
利用 Cookie 记录 Session
Session 服务器
版权声明: 本文为 InfoQ 作者【escray】的原创文章。
原文链接:【http://xie.infoq.cn/article/8c25746e79b32d94bc0484d27】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论