架构师训练营第五周 - 总结

用户头像
桔子
关注
发布于: 2020 年 07 月 09 日
  1. 分布式缓存架构

  2. 缓存的关键指标

  3. 缓存命中率:就是查询n次缓存,有多少次得到了缓存

  4. 影响命中率的3个因素

  5. 缓存的key:因为缓存键主要是Hash存储,所以缓存键重复概率要低

  6. 进程内存的大小:缓存能使用的内存越大,能容纳的缓存就越多

  7. 缓存的存活时间:缓存的存活越久,被重用的可能性就越大

  8. 缓存的分类

  9. 代理缓存:一般在客户端网络,比如公司出口网关、甚至比如浏览器缓存也算一种

  10. 反向代理缓存:一般架设在应用服务器前面,为客户端提供响应,比如NGINX、HaProxy等

  11. CDN内容分发网络:缓存静态文件,而且分布在全国各地

  12. 旁路缓存:让客户端自己先请求缓存,不存在再请求数据服务,客户端复杂了。

  13. 分布式对象缓存:在多台缓存服务器存放不同的缓存数据,减轻单台缓存服务器的压力

  14. 一致性Hash

  15. 由于分布式缓存架构,在扩容或单台崩溃时,可能带来缓存大批量失效的风险,从而造成缓存大量穿透,最终雪崩的场景,因此提出了一致性Hash的架构方案。

  16. 同时,一致性Hash可能带来服务器压力不均衡,所以通过要通过增加虚拟结点的情况来改善

  17. 验证一致性Hash算法是否均衡,要通过计算标准差的方案来衡量

  18. 标准差计算公式

  19. (每个样本 - 平均值)的平方 / (服务器数 - 1),结果再取平方根

  20. 平方根的结果跟平均值越接近,表示算法的质量越好,分布越均衡。

  21. Java里一般使用SortMap或TreeMap红黑树来实现一致性Hash

  22. Redis不使用一致性Hash,而是使用了桶的方案进行数据分片,Memcached使用一致性Hash,服务器之间不共享信息,甚至服务器都不知道自己在集群里,架构相对简单一些。

  23. 缓存穿透、缓存雪崩及缓存预热

  24. 缓存穿透

  25. 客户端持续请求某个不存在的缓存Key,导致数据请求落在后端数据库上。

  26. 缓存雪崩

  27. 最初由于一些缓存穿透,导致数据库压力过大,从而使系统各个部分因数据库宕机而崩溃。

  28. 缓存穿透的避免方式

  29. 把不存在的数据也进行缓存,但是要设置较短的缓存时长。

  30. 对于热点key,且数据不敏感的,也可以对请求数据库加锁,其它无缓存请求直接返回空。

  31. 缓存扩容相关时机及方案

  32. 时机

  33. 业务低谷时

  34. 避免压力方案

  35. 一定程度的预热,把数据提前载入缓存服务器。

  36. 消息队列与异步架构

  37. 消息队列一般用途

  38. 异步处理,快速响应,提升用户体验,加大服务器吞吐量,但是结果需要异步回调,或轮询的机制,会比同步方案复杂一些

  39. 削峰填谷

  40. 消息按一定的速率进行消费,这样即使短时间来了大量消息,也不会对消费者造成冲击,这是削峰;在消息生产者压力回落的谷底时,持续消费,这是填谷

  41. 业务解耦

  42. 把强耦合的2个服务进行解耦,降低服务之间的复杂度,提升可维护性,比如:支付服务在支付完成,只需要发个消息出去,不关心谁来消费消息,其它服务想了解,就去订阅这个消息即可。

  43. 负载均衡架构

  44. 降低单台后端服务器压力,提升整个系统的横向扩展能力。

  45. 负载均衡方案

  46. 应用层代理,比如Nginx、HaProxy在http层代理,提供了强大的转发支持,但是效率低下,因为需要解析比较多的数据包信息;

  47. 3层ip层均衡

  48. 2层数据链路层,进一步提升效率,但是只能在同一网段,比如LVS。

  49. 数据库同步方案

  50. 主从同步、双主同步。



用户头像

桔子

关注

还未添加个人签名 2018.11.15 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第五周 - 总结