1.mysql和redis的区别
mysql是一种关系型数据库，数据会最终存储在磁盘上。而redis是一种非关系型的nosql数据库，以key-value的形式存储数据，将数据存储在内存。从性能上来说，redis将数据存储在内存，性
能肯定要优于mysql数据库。但是从安全的角度来说，mysql数据存储在磁盘上更安全些。所以我们在项目中一般会将redis和mysql结合使用。
2.redis的事物
redis事物执行过程说明:redis对事物的支持比较简单，能够保证一个客户端发起的多个命令可以被连续的执行。我们清楚，在redis中和事物相关的关键字有multi（表示开启一个事物），
exec（表示执行一个事物），discard（表示回滚一个事物）。在一般情况下（没有开启事物），redis的client端发起一个命令到redis的server端，命令会直接执行并将结果返回给client。但是
当我们使用multi开启一个事物时，client每发出一个操作，server端会将这个命令放入到一个队列里面，直到客户端发出exec提交命令时，server端会将这些命令一次执行。并将执行的结果打包
发送到client，结束这个事物的执行。
我们清楚关系型数据库mysql的事物一般支持ACID，即原子性，一致性，隔离性，持久性原则，但是在redis中，这些原则并不都支持。
原子性：在上面的分析中，我们已经清楚，一个client端执行multi命令开启一个事物，会进入到一个事物的上下文，之后所有的命令会被放到执行队列，直到发出exec命令后，server端会依次
执行这些命令并将执行结果返回，并且释放上下文。但是在这里面有一个问题，就是当队列中有一个命令出现错误时，并不会发生回滚，而是会继续执行后面的命令。这就违背了事物的原子性原
则。这是redis事物存在的第一个问题。
一致性：
隔离性：redis在执行一个事物队列中的命令时，其它的client是无法执行命令的，所以它满足了隔离性。
持久性：通过前面对事物的分析，我们已经清楚redis的事物只不过是执行队列中存储的一系列的命令，执行完成之后数据依然存储在内存。它的持久性其实与事物并没有多大的关系，而是与我
们所设定的redsi的持久化方案有关。当我们没有启用redis的持久化时，所有数据都是存储在内存，当然不存在持久性。当我们使用rdb模式的持久化方案时，如果在redis事物执行完成之后到执
行rdb文件更新这段时间服务器出现问题，事物提交的数据的持久性也无法得到保证。当我们使用aof模式的持久化方案时，命令的执行由主线程来完成，持久化由后台线程来完成，但是主线程不
会阻塞等待后台线程完成任务后在执行，中间出现时间差，所以也不一定会保证持久性。
redis事物存在的问题:
1.无法满足原子性，队列中某条命令执行错误时，并不会回滚，而是会继续执行下面的命令。
2.假如我们在一个事物执行之前查询出一个key，然后在这个事物中对这个key执行加1的操作。但是我们在事物提交(exec)之前某个客户端对这个key做了修改，由此我们就无法达到我们的要
求。redis在这块所做的努力是引入watch机制，我们在获取key之前，对这个key执行watch命令，然后执行事物中，只要这个key发生任何的变化，这个事物不会执行成功。