Blog of YHR

Ch00 Note01

11/5/2023 architecture

#

# 主要记录一些见过的架构设计

# Redis

image-20231102190157109

# 资源管理

image-20231105222310695

image-20231105222324112

  • 主从混部，在从节点上有RDB备份，AOF备份，导致会有cache，如果cache过多，但是free不足，可能会触发操作系统的低水位回收，会对redis的性能影响很大
  • 所以有drop_page_cache这个脚本保证机器有足够的内存给redis使用
  • redis一般内存不会满，有阈值，超过阈值用LRU淘汰
  • 热点key分析是用RDB，不会造成性能影响
  • 当负载过高的时候，会抓取短时间的请求进行分析
  • 客户端直接分片是最快的，因为可以直连，比proxy那种的好很多

# 集群部署

image-20231105222826359

  • 因为同一个集群可能产生流量激增，如果不分片打散的话，可能会导致同一台机器扛不住

image-20231105223748787

# 自动化迁移

image-20231105223917626

image-20231105224048413

# 集群扩缩容

image-20231105224351508

  • 通过迁移的方式进行扩缩容，通过redisgate进行重新分配image-20231105224702710

  • redis gate实际上也是一个redis节点，但是在load RDB的时侯，函数经过改造，增加一个ReplicationToServer() 方法，来对数据进行分发image-20231105225038245

  • hsetCommand是redis会把RDB转换成一条一条命令来写入

image-20231105225345123

  • 自动扩缩容image-20231105225623323
    • 数据校验：采样
    • 扩缩容会全局重连（交换namespace），但是故障只会单节点重连

# 巡检，告警，监控

image-20231105225843114

image-20231105230103789

image-20231105230411015

  • 比如redis上云之后，大部分其他业务机器还在本地，那么访问有延迟

# Mysql

  • 用MHA来监控有单点的问题，解决方案是用Orchestrator，是开源的mysql高可用，拓扑的可视化管理工具，检测，故障转移的组件，有UI界面，在此场景下也可以作为mysql的配置中心

image-20231102192840450

image-20231102193336114

image-20231102193521663

  • 在挂的时候千万不能自动切换，因为会有数据不一致性的问题

# 为什么微服务与高并发程序都在放弃 Zookeeper

  • CP设计，太慢了