有以下几个原因可能会导致客户端异常：
由于存在网络传输，网络抖动可能会偶发操作失败。
客户端所在服务器负载过高时，可能会造成处理缓慢，最终造成超时。这是出现超时的绝大多数原因，所以可先排查客户端所在服务器历史负载记录，是否有满载现象。
操作步骤
登录阿里云控制台。
将鼠标放在右上方的用户名区域，在弹出的快捷菜单中选择accesskeys。
系统弹出安全提示对话框，单击继续使用AccessKey。
页面显示Access Key ID和Access Key Secret。
支持特性对比
支持的不同协议对比
特性 Redis 4.0集群 codis集群 阿里云Redis集群 事务 支持相同slot 不支持 支持相同slot sub/pub 支持相同slot 不支持 支持 flushall 支持 不支持 支持 select 不支持 不支持 支持 mset/mget 支持相同slot 支持 支持水平扩展对比
Redis 4.0 cluster、codis、阿里云redis分布式集群均实现了面对slot的管理，扩展的最小单元是slot。
分布式集群水平扩展的本质是对集群节点的路由信息管理以及数据的迁移。3种集群迁移数据的最小单位均是key。
Redis cluster水平扩展原理
Redis 4.0 cluster支持指定slot在节点中移动，也支持加入空节点后根据集群节点中已存在的slot分布自动进行再分布。以redis-trib的move_slot为例解析slot移动的过程：
调用setslot命令修改源、目标节点slot的状态。 获取源节点上slot的key列表。 调用migrate命令迁移 key，迁移过程中redis属于阻塞状态，只有目标节点restore成功后才返回。 调用setslot命令修改源、目标节点slot的状态。迁移过程中如何保证数据的一致性？
Redis cluster提供迁移状态中的重定向机制，向客户端返回ASK，客户端收到后需先发送asking指令到目标节点上，然后再发请求到目标节点上才可以访问。当访问的key满足以下全部条件时会出现重定向返回：
key所属slot在该节点上。如不在，返回的是MOVE。 slot处于迁移状态中。 key不存在。如上所述，migrate是一个同步阻塞型的操作，如果key并不为空，即使slot处于迁移状态，key依然能被读写，以此保证数据的一致性。
codis水平扩展原理
codis对slot的再分布策略与redis cluster相同。codis-server内核并没有存储slot的信息，也不解析key所在的slot，只有在dbadd等操作时将对应的key记录到以slot为key的dict中。如果key带有tag，则将tag做crc32运算后将key插入到以crc32值为key的skiplist中。
codis Dashboard后台起迁移状态机程序，先确保通知到所有proxy开始迁移，即prepare阶段，如有一台以上proxy失败，则迁移任务失败。迁移步骤与redis cluster类似，不同点是：
slot状态信息存储在zookeeper/etcd。 发送slotsmgrttagslot而非migrate指令，slotsmgrttagslot执行时会随机获取一个key迁移，如key带有tag，则从上文中的skiplist获取所有key批量迁移。迁移过程中如何保证数据的一致性？
codis同样也是同步阻塞型的迁移操作。在保持数据一致性方面，因为codis-server内核不维护slot的状态，所以一致性的保证落在了proxy组件上。codis-proxy在处理请求时，先判断key所在slot的状态，如slot处于迁移中，则向codis-server发起指定key迁移的命令，等key迁移完成后，codis-proxy转向目标的codis-server请求。做法简单，对redis内核修改较少，但同时也导致迁移慢，客户端卡住的时间较久。
阿里云redis水平扩展原理
阿里云redis除了提供指定源、节点、slot外，还提供按节点的容量、slot的大小等考量参数动态分配slot，以最小粒度影响集群可用性作为分配原则。迁移大体步骤如下：
由redis-config计算源、目标节点、slot。 redis-config向redis-server发送迁移slot指令。 redis-server启动状态机，分批量迁移key。 redis-config定时检查redis-server并更新slot状态。迁移过程中如何保证数据的一致性？
与codis不同，阿里云redis在内核上同样维护了slot的信息，并且抛弃了codis迁移整个slot和redis cluster迁移单个key的做法，从内核上支持批量迁移，加快迁移速度。
阿里云redis迁移数据是异步的流程，不等待目标节点是否restore成功，由目标节点通知和源节点定时检查来验证是否成功。以此缩小同步阻塞对其他slot访问的影响。
同时也是因为迁移异步化，所以在保证数据一致性时，如果是写请求并且key存在于不在迁移的key列表中，走正常的写请求流程。其他数据一致性保证与redis 4.0 cluster相同。
阿里云redis-server优化了迁移大key的流程，详情见 https://yq.aliyun.com/articles/64884 。
