心跳处理的必要性: 服务端需要同时处理上千甚至上万的客户端的连接,所以每个连接资源都是很宝贵的,当客户端断开连接的时候服务端应该及时移除该连接。 正常情况下,客户端断开连接的时候,会和服务端进行四次挥手,服务端就会知道这个连接 已经不能用了优雅的退出监听消息。但是总会有意外,比如客户端忽然断网了,没电了,这个时候客户端肯定不可能按照流程和 服务端进行挥手,不知道消息的 服务端还傻傻的在哪儿等着,不知道客户端早就走了。 这个时候 心跳包就很完美的解决了此问题。客户端和服务端约定好每隔一段时间 就会发消息,如果服务端每过一段时间没有收到客户端 的心跳消息 就说明 客户端出事了,服务端就删除此连接,确保 资源最大化。 一般心跳包就是 符合该协议的 最小包。 一般的go语言框架都是一个连接单独开一个协程 去处理读取超时问题 当协程数量多到一定程度的时候,协程之间的调度也是一个很大的 消耗 一个协程 进行 心跳检测。
加上一台服务器,然后 修改网关服务器的配置表 加上 新加的 服务器的IP 和端口,然后重启网关。还有就是 当 后面的 服务器万一 down 了,网关是不知道的,还会把 流量转发到 down的 服务器上,造成 服务的不可用。
Redis 集群中内置了 16384 个哈希槽,当需要在 Redis 集群中放置一个 key-value时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,
https://github.com/afex/hystrix-go/ 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择. 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者, 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: