迫真分布式设计-狐思乱想

微信扫一扫,分享到朋友圈

迫真分布式设计-狐思乱想
0

核心设计

本文不接受任何抬杠,谢谢,是摸鱼的时候狐思乱想的杂文哟(如果实现的会最近会做吧)不喜欢就直接右上角吧,不是什么干货

(咱就是个cs垃圾quq)





  1. 每个Slave节点的Cron会每分钟给Master节点上报一次服务器信息
  2. Master节点检测如果Slave节点五分钟没上报信息,则认为Slave节点已经Down机,记录状态并发到通知系统
  3. 无论Master节点还是Slave节点数据库并不存在主从/主主,每个节点都有自己的数据库
  4. 当Master节点将Slave节点判断为Down机会自动将此信息下发到其他Slave节点
  5. 当通知Slave节点同步重要数据库完全失败(有重试机制),则Slave节点判断为Down机并下发其他通知节点
  6. Master节点会像Slave节点发布需要同步的数据(一般为设置同步以及节点列表)
  7. Slave节点若请求Master节点失败,则会通过同步过来的节点数据库请求其他节点,进行判断若Slave节点请求不通则不操作,若Slave节点请求成功则内部进行选举/按优先级,通过阿里云DNS/DNSPOD将解析记录改到Slave节点,此时Slave节点变为Master节点,新的Master节点只会处理Slave节点时已经同步在数据库的数据,不会处理已经Down机的Master节点的未处理的数据(该系统主要用于提供API,需要关联的操作不多),若Down机Master节点重新上线则会变成Slave节点。
  8. Master节点添加Slave节点会自动通过DNS API分配一个域名
  9. 节点UUID是唯一识别码(不认ip地址)
  10. 当Master节点产生,Master节点无论DNS解析是否成功,部分功能都将运行(例如通知系统)
  11. 若Slave节点状态正常且收到需要处理的API请求,部分API可直接返回结果,部分需请求Master节点获取许可
  12. 若出现Master节点Down机进入切换,在切换途中Master节点恢复则Master节点会对API请求返回错误/拒绝处理/转发API至其他节点 视API而定
  13. 符合这套系统接口的程序,都可以进行由Master节点进行节点管理
  14. 不同功能Master节点会使用DNS API将一个子域名解析至Slave节点,当Slave节点Down机那么Master节点会自动将子域名通过DNS API解析到新的Slave节点
  15. 若支持部分功能且支持接口的其他系统,可以作为Slave节点,但不可选举为Master节点(无论Slave节点如何实现功能只要支持接口且功能可用即可成为Slave节点并分配子域名以及服务域名)




备注

  1. 数据库采用Mysql处理,原计划使用ETCD
  2. 本实现并不需要网站服务器(Apache Nginx…),甚至可以在虚拟空间上实现
  3. 该分布式设计是实现在多台服务器应用部署以及DNS记录之间,与其他分布式设计拥有较大差距
  4. 本节点管理与资产管理是两个完全不同的功能,节点管理只管理服务
  5. 不使用Mysql主从同步/主主同步以及ETCD数据库是故意的设计的
  6. 不使用DNS负载均衡/其他负载均衡服务是为了需要支持更多的功能
  7. 主要提供API服务,对服务之间的关联性不强
  8. 资产管理的Agent会协助该分布式设计的实现
  9. 在可能的情况除了使用dns解析记录还会最大程度的与BGP Anycast结合
  10. 本方案并非轻量级/成熟解决方案可能只适用于该系统
  11. 本分布式设计方案非最优设计,仅适用于该系统
  12. 本分布式设计不支持会话同步
  13. 部分设计是为了Admin System的资产管理功能
  14. DNS缓存以及同步问题会通过同步的节点数据库解决
  15. 是网络操作都会出现问题
  16. 系统的API主要为无状态API
  17. 若出现数据问题,每个节点会校对各自的history库来解决问题
  18. 该方式进行节点切换恢复时间较长,预计五分钟内恢复使用(瓶颈在DNS)若支持BGP AnyCast则速度更快

咱很菜的,是个智障。 人设非常容易崩。

你也可能喜欢

发表评论

您的电子邮件地址不会被公开。 必填项已用 * 标注

提示:点击验证后方可评论!

插入图片
返回顶部