![](https://img-blog.csdnimg.cn/20201014180756918.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
高可用
文章平均质量分 79
从高可用问题产生的可能场景进行系统性分析,解析各个场景下高可用问题的解决方案
shin_chen_名字不要重复
偶尔更新一下
展开
-
高可用系列六:服务监控
服务监控的目的是为了尽早发现出现的问题,减少或避免可能造成的损失。监控首先要解决的问题是监控什么,即监控的方法,其次是如何有效告警,最后是如何跟踪处理告警。原创 2024-05-27 14:58:49 · 460 阅读 · 0 评论 -
高可用系列五:注册与发现
注册与发现,主要需要解决的就是服务如何找到可用的依赖服务实例。即需要在注册中心尽量保持服务的健康状态,这里用尽量,则是因为保持状态一致性的复杂问题(详细可了解CAP概念)。因此几乎所有的注册中心服务设计,CAP的选择上都是AP架构,产生的短期不一致问题,则由其他方面,如负载均衡结合重试机制来实现。原创 2024-05-27 14:56:28 · 372 阅读 · 0 评论 -
高可用系列四:loadbalancer 负载均衡
负载均衡可以单独使用,也常常与注册中心结合起来使用,其需要解决的问题是流量分发,这是就需要定义分发策略,当然也包括了故障切换的能力。负债均衡也是高可用中很重要的一环,而且巧用负载均衡,还可以实现开发环境中降本增效的效果。原创 2024-05-02 18:05:18 · 723 阅读 · 0 评论 -
高可用系列三:事务
都成功或者都失败是事务目标,实际中往往会采用最终一致、最大努力一致和不一致时人工介入策略。评估事务,通常会根据业务特点,考虑对于事务相关业务之间所需的时效性、依赖联系因素,框定事务可用方案,并结合事务实现代价综合评定选择事务方案。实际过程中事务的解决需要根据业务的特定来进行方案选择,而且也可能是一个长事务采用多种方案结合的方案,利用消息中间件是一种有效的降低复杂度和提升可维护性的方案,单采取该方案实现有明显的副作用,一是延迟,二是消息监控问题。原创 2024-05-02 18:03:40 · 639 阅读 · 0 评论 -
高可用系列之重要的小点:请求/重试机制
请求/重试机制这个点虽然非常非常重要(详情请看),但确实能说的不多,当然关键点还是有的。首先就是超时时间的设置,一般有两个值,connectTimeout 和 socketTimeout(有些地方也叫 readTimeout)。其次是重试的逻辑。原创 2024-04-10 18:24:15 · 344 阅读 · 1 评论 -
高可用系列二:绝对核心——服务请求幂等
服务请求幂等,简单地解释可以为同一次请求,因为各种原因重试时得到的结果一致或者可被识别,这里的结果一致指的是对于平台数据的变更影响,比如重复提交同一订单,会不会生成重复订单。从上一篇(高可用系列一:高可用问题是如何产生的)分析可以看出,请求幂等在高可用场景是非常重要的一环。原创 2024-04-10 17:18:06 · 706 阅读 · 1 评论 -
高可用系列特殊场景:第三方限时唯一访问令牌
很多第三方服务,都使用访问令牌来做访问验证,比如某度、某信的access token,主要特征如下:1、令牌由第三方系统发放,用于访问第三方特定资源;2、令牌存在有效期限,过期自动失效;3、同时只存在一个有效令牌,重新获取后之前获取到的令牌将会过期(这一点不是每个平台都严格限制,我们假设严格限制)。原创 2024-04-05 17:02:16 · 256 阅读 · 1 评论 -
高可用系列一:高可用问题是如何产生的
总得来说,我们在实现系统高可用时,目的是为了尽量让用户持续得到正确的结果,实现产品价值。当然从研发团队来说,这一系列措施是增加系统的被信赖关系,同时也很重要的一点是避免让开发人员陷入持续的救火中。一般需要采取的措施主要如下:1、系统版本推送与刷新机制、服务地址动态获取2、超时、重试机制,引申问题:请求幂等、服务发现与负载均衡策略3、多实例部署,避免单点,引申问题:服务发现、服务状态维护、服务伸缩4、资源池的合理管理5、服务熔断、服务限流。原创 2024-04-05 16:12:03 · 734 阅读 · 1 评论