吐槽 aws elasticache

近日使用aws的elasticache出现了异常的切换。而且这种切换的频率非常高，导致每次切换的时候我们的服务都会出现一些波动。

Recovering cache nodes 0001 - -
Failover to replica node aws-xxxx-0003-001 completed - -
Test Failover API called for node group 0003
Snapshot failed for snapshot with ID ‘automatic.aws-xxxx-2024-03-25-20-00’ of replication group with ID ‘aws-xxxx’

但是我们的服务请求一直是比较平缓的，不可能出现那么多的问题。 于是就给aws提交工单，可提交过去居然6天都没有任何回音，工单里问一下就说还在排查中，于是只能请求aws内部人员催一下。

然后跟aws的支持人员进行在线会议沟通，在会议中aws认为就是我们使用的swap太多导致的切换，老实说用了那么多年的云厂商的redis，swap这个指标在其他云厂商里是没有见过的，本来aws的redis买的时候就只能使用75%，你不会拿swap来当内存来忽悠客户吧。

会议中又来一个据说高级支持人员，上来就说这就是我们使用不当导致的，为什么就你们使用产生那么多swap，就为什么你们使用产生那么多连接。真是好大的官威啊。我说那你们就dump一下swap内容来出来看看到底是什么呀，人回答说这个可导不出来，我说我们授权你们导出总可以吧，然后就一堆巴拉巴拉说各种不行。

最后终极说法就是为什么就你们出现问题，别的客户没有问题。这可不就是你们的问题吗？你们的redis客户端都传了什么东西导致我们的redis使用大量swap。

于是我们就先内不能检查了一下最近的发版，发现跟这些并没有关系，研发都没有升级过redis client，而业务上说更是没有问题，不可能所有redis实例都出现问题，我们所有服务都是微服务的，每个微服务都是各自独立的redis实例，不可能都出现问题。

然后我们就发现是从3月25日开始异常重启的，那就看看对应监控项。

果然看着这个swap是从2月29日开始异常的飙升，而之前swap的使用率是非常低的。

再看了一下connection的监控,发现是从2月24日开始，并发连接数异常增加，但是新建连接数并没有变化，那基本说明不是我们服务连接导致的。

而且正常2000多的连接，就算一个连接4K，那2000多个连接不也是就8M内存，这2G的内存具体是什么还是不知道。

为了防止是个例的问题，我们又看了新加坡和法兰克福地域的所有该规格(cache.t4g.small)的所有实例，发现他们表现形式都一样，时间点也一样，但是美东地区该规格的实例却正常，非常的平缓，跟之前没有任何区别。

不过官威很大的支持还是说这应该是你们发版导致的，为了证明他的问题，网上找了别家使用的实例，发现 cache.t4g规格的也确实如此，只是别人用量小，但是陡增的斜率是完全一样的。

好了，aws看来升级也是有先后，海外先进行，美帝自己本地是最后来更新。后面就等着aws自己去修复了。

怎么说了，aws这些支持也得分人，有些就是纯粹甩锅的，有些还是很技术的说明，虽然我们认为不合理，但是对方至少会把规则说清楚，并且能够证明。

而且我们根本不用迷信aws，感觉aws至少在数据库上做的并不好，首先redis切换，主从切换的时间都要1分钟以上，国内的厂商一般都控制10多秒内。aws的主从切换异常的时候redis里的数据就都没有了，而不是说拉起一个最近的备份。导致cache数据的全部丢失。按理说aws本身有备份，你加载一下并不会多花多少时间，但是感觉aws就是不干这种事情。

还有什么MySQL升级这种事情，非要搞个蓝绿部署，前后切换时间至少要5分钟以上，这当中还一堆人工的操作，说是要保证binlong能够追上等等，这些国产的云厂商早就做到系统里了，虽然可能不一定很完善，但是至少人是朝着更便捷的方向在努力的。

后记： aws的开发团队终于确认了他们自己的问题，并且很快的修复了。 其实我理解这个问题从开发角度是很容易处理的，只是测试不完全，我理解他们也是一点点在灰度的。但是他们支持团队的个别人就是在当中瞎搅糊。