文章目录
- 什么是bigkey，有什么危害，怎么查找？
- redis事务介绍
- redis事务和关系型数据库事务对比
什么是bigkey，有什么危害，怎么查找？
一个key对应的value占用的内存较大，就把这个key看做是bigkey。具体多大内存的value才算bigkey，根据场景自定义。
bigkey会消耗更多的内存空间，对性能也有较大的影响，导致CPU占用率高、网卡带宽跑满等问题。
因此尽量避免bigkey。
查找bigkey：redis中查找大key方法汇总 例如分析 RDB 文件，前提是你的 Redis 采用的是 RDB 持久化：redis-rdb-tools
redis事务介绍
注：通常用lua脚本保证原子性，而不是redis事务。
redis事务可以理解为：打包一组命令请求，顺序执行，并且不会被中途打断。
过程：三个阶段
开始事务（MULTI）
命令入队（事务队列，先进先出）
执行事务（EXEC）
可以通过DISCARD命令取消一个事务，该命令会清空事务队列中保存的所有命令。
可以通过WATCH命令监听指定的键，只能在MULTI命令之前执行，当调用EXEC执行事务时进行检查，如果一个被WATCH监视的键被其它客户端修改，整个事务都不会执行，直接返回失败。
WATCH命令的底层实现中保存了watched_keys 字典，字典的键保存的是监视的key，值是一个链表，链表中的每个节点值保存的是监视该key的客户端。
可以通过UNWATCH命令取消监视之前通过WATCH 命令监视的key，通过执行EXEC 、DISCARD 两个命令之前监视的key也会被取消监视。
两种错误的错误处理：
语法错误：语法错误往往客户端就能自动检测，即使命令进入队列，只要存在语法错误，该队列中的命令都不会被执行，会直接向客户端返回事务执行失败的提示。（类似于mysql的预编译）
运行错误：如果操作命令的类型与数据的类型不匹配，命令在执行时会报错，但是仍然能进入队列。正确的命令被执行，而错误的命令执行时报错，这也显示出Redis的事务并不能保证事务的原子性，因为中间出现了错误，有些语句还是被执行了。
redis事务和关系型数据库事务对比
数据库事务的四大特性：ACID
A原子性：事务是最小的执行单元，不可分割。保证动作要么全部执行，要么全部不执行。
C一致性：事务执行前后，数据的状态保持一致。
I隔离性：事务在执行时，不会受到其它事务的干扰，各并发的事务之间是独立的。
D持久性：事务一旦执行完毕，执行这个事务所得的结果就会被保存到 永久性存储介质中，不可更改。
但是，Redis事务中也没有像Mysql关系型数据库事务隔离级别的概念，Redis也不支持回滚操作，当事务队列中有命令执行失败时，不会回滚，仍然会继续执行，因而不满足原子性。
Redis 通过单线程的方式来执行事务以及事务队列中的命令，并且在执行事务期间不会对事务进行中断，因此事务总是满足隔离性。
Redis事务的持久性由服务器所使用持久化模式决定。仅在开启AOF持久化并且设置appendfsync=always时，才能保证绝对的持久化。
开启RDB快照持久化是不能保证持久化的，因为需要满足一定条件才会触发BGSAVE操作保存数据库的快照。（60s内至少10000次更改/ 300s内至少10次更改 /900秒内至少 1次更改）
Redis不支持回滚、事务隔离级别的原因：
Redis的特点就是快速、高效。回滚、为了实现隔离级别而加锁、解锁等操作，会消耗大量资源，影响redis性能，违背了redis设计的初衷。并且官方认为执行中的错误在开发中就很容易被发现，而不是在生产环境中被发现。
redis事务可以理解为：打包一组命令请求，顺序执行，并且不会被中途打断。而无意实现传统事务的ACID特性。
