ElastiCache下Redis LIST并发LPUSH致数据损坏，求问处理机制

咱们先把核心结论摆出来：Redis的LPUSH命令是完全原子的，并发执行绝不会导致元素内容损坏或混入日志这类奇怪数据。你遇到的问题，根源肯定不在Redis/ElastiCache的LPUSH并发处理上，得从客户端、代码或者传输链路找原因。

一、为什么LPUSH并发不会出问题？ #

Redis是单线程处理所有命令请求的——不管多少客户端同时发LPUSH到同一个key，这些命令都会被放到一个队列里串行执行。每个LPUSH命令都会完整地把指定元素推入列表，中间不会被其他命令打断，也就不可能出现元素内容互相拼接、混入其他数据的情况。哪怕是ElastiCache的集群模式，key会被路由到特定分片，分片内的命令依然是串行处理，同样保证原子性。

二、你遇到的元素混入日志，大概率是这些原因 #

你给出的损坏元素里有Sync*3 $5 LPUSH $8 cadvisor...这类内容，看起来像是Redis协议格式的命令片段或者客户端日志，这绝对不是Redis服务器端搞出来的，可能性最高的几个点：

• 客户端SDK的bug：比如某些旧版本的Redis客户端在处理大元素、批量命令时，缓冲区管理出问题，把日志内容、命令元数据不小心拼进了要LPUSH的元素里。我之前碰到过某语言SDK在开启调试日志后，把日志输出串进了命令参数的情况。
• 代码逻辑失误：检查你的应用代码，是不是在处理Redis写入的同时，把日志内容误写入了Redis的请求缓冲区？比如调试时的print语句、日志框架的错误配置，导致日志和要发送的value混在了一起。
• 网络传输异常：虽然在ElastiCache这种托管服务里概率极低，但TCP粘包、断包重传异常也可能导致Redis收到的请求内容混乱。不过这种情况通常会伴随其他错误，比如命令执行失败，而不是元素损坏。

三、ElastiCache的额外排查点 #

ElastiCache作为托管Redis，和原生Redis行为一致，但可以多查这几点：

• 如果是集群模式，确认key的路由是否正确——不过就算路由错了，也只会导致元素进错分片，不会出现内容损坏。
• 检查ElastiCache的节点日志（比如CloudWatch里的日志），看有没有相关的错误记录，但可以肯定的是，服务端日志绝不会主动混入用户数据。

四、快速排查建议 #

1. 抓包验证：在客户端机器上抓TCP包，看看发送给ElastiCache的LPUSH命令里是不是已经包含了错误的日志内容。如果是，那百分百是客户端代码或SDK的问题。
2. 升级客户端SDK：直接把你用的Redis客户端更到最新稳定版，很多旧版本的缓冲区bug已经被修复了。
3. 隔离测试：写个极简的测试程序，模拟多客户端并发LPUSH，然后读取列表内容。如果测试程序没问题，那就是你业务代码里的特殊逻辑导致的。
4. 排查DEL操作：虽然DEL是原子操作，但你是LRANGE后DEL，有没有可能在这两个操作之间，其他逻辑修改了数据？不过DEL只会删整个key，不会损坏元素内容，这个可能性极低。

内容的提问来源于stack exchange，提问作者Marius