K-V存储（Redis）：用数据结构服务器换取部分ACID

[[NoSQL的本质定位是针对关系数据库四大缺陷的补充方案]]里K-V存储针对的是”关系数据库无法存储数据结构”这个缺陷，Key对应关系数据库里主键的作用，Value才是真正的数据本身。以Redis为代表的K-V存储的关键特点是Value本身可以是丰富的数据结构（string、hash、list、set、sorted set、bitmap、hyperloglog等），因此常被称为”数据结构服务器”而不只是简单的缓存。以List结构为例，Redis原生支持LPOP（从队列左边弹出一个元素）、LINDEX（按索引取元素）、LLEN（取队列长度）、RPOP（从队列右边弹出一个元素）这类操作；如果同样的语义要用关系数据库实现，就要给每条数据额外维护一个”位置编号”字段（不能直接用行ID，因为要支持往列表头部插入数据），实现LPOP要先查出第一条数据、删除它、再把从第二条开始的所有记录的位置编号依次前移更新——需要多次SQL操作才能完成一个Redis原生一条命令就能搞定的语义，性能自然差很多。Redis的代价是不支持完整的ACID事务：它虽然提供事务功能，但只能保证隔离性和一致性（I和C），无法保证原子性和持久性（A和D），这一点和关系数据库的事务完全不是一回事。不过这个限制不该被当成”不能用Redis”的理由——很多业务场景本身就不需要严格遵循ACID，比如微博的关注操作，即使系统偶尔没能把A成功加入B的粉丝列表，业务影响也很轻微，是否适合用Redis，最终要结合具体业务对一致性和持久性的真实要求来判断，而不是一刀切地因为”不完全ACID”就放弃。