Redis设计初衷-->高并发,高可用,处理海量数据
高并发-->性能要优秀-->所以,在保证安全的情况下,删除一些不必要的降低性能的操作
- Mysql事务-->依靠锁实现,读共享锁,写独占锁-->独占锁会导致请求堆积,大大影响性能
⬇
-
- Redis实现了类似于Java JUC包中的乐观锁CAS机制的watch机制
在事务之前对要执行写操作的key加监控,在此事务提交之前会检测此时值是否与之前值相等,如不相等则不进行提交
此时,不会出现排队现象,乐观锁的实现使得性能大幅度地提高
-
- 事务执行时,语法错误不会提交
但,语法正确,但运行时的错误(如语句不适合此类型)不会回滚,Redis没有回滚这个概念-->回滚需要保存回滚前数据,一定程度上影响性能
因为一定程度上运行时错误在测试过程中可以避免,所以这种错误也会执行事务提交
- 主从复制/读写分离+哨兵机制-->实现高可用并提高性能
⬇
主服务器只负责写操作,从服务器只负责读操作,各司其职,有利于因材施教,定制自身行为
并且读写分离,多个从服务器分担了读的压力
主从复制以及哨兵机制的配合,实现了高可用,奇数个哨兵实时监测主服务器的运行状况,且互相交互数据,多个哨兵检测到主服务器出现宕机,奇数个哨兵少数服从多数进行从服务提升,其余从服务器重新挂主行为,大大实现了高可用
事务 : http://www.bjpowernode.com/tutorial_redis/337.html
持久化 : http://www.bjpowernode.com/tutorial_redis/338.html
主从复制 : http://www.bjpowernode.com/tutorial_redis/339.html
哨兵机制 : http://www.bjpowernode.com/tutorial_redis/340.html
安全设置 : http://www.bjpowernode.com/tutorial_redis/341.html