在我眼里的mysql与redis的区别

1

redis可以你当做nosql内存数据库用, 而mysql是我们耳熟能详的关系型数据库.

关于他们之间的区别, 你google一下, 一大堆一大堆的分析, 那些词汇看的我天花乱坠, 仿佛把redis吹上了天.

不过我发现大家好像都忘记了一个在实际开发中更容易想到的优点. 我接下来就来说说

2

和oracle不一样,mysql不存在什么序列锁,所以写代码的时候要非常小心并发问题带来的数据异常. 不过这些对于现在的java社区来说已经不成问题. spring框架对数据库的事务支持相当的优雅, 我们只需一点点配置,就可以精确的控制事务的范围,事务的级别.

但是我们退一步想,如果因为一些原因,公司需要开发自己的IOC容器,AOP框架这些玩意. 这时候,我们就没法偷懒了. 事务控制这些就必须自己写.

我前面也说了和oracle不同,oracle存在一种叫序列锁的东西,所以在编写代码的时候,做一点点的同步控制, 就可以有效防止因数据一致性问题引发的数据异常问题

直到现在为止, 最新的mysql8, 使用默认的事务级别REPEATABLE-READ , 在多线程同时执行读写的情况下,依旧会发生这类问题. 有疑问的可以自己去测试下,开两个mysql客户端,然后同时开启事务A和B, 在A事务中更新一个flag值,在B事务中flag值依旧是旧的. 这会导致代码中if判断的逻辑和业务不符.

不过这并不怪mysql, 因为mysql官方对于事务级别REPEATABLE-READ并不提供这方面的解决方案,因为它们已经有了串行化事务级别.

但是由于硬盘IO效率低, 使用串行化, 发生堵塞最后影响性能是必然的, 所以现在都是用高级语言去进行同步控制, 会比mysql自己处理性能更好.

但是redis单线程架构+内存操作速度快, 故事就不一样了, 可以说省了不少事,下一节慢慢说

3

上一节我吐槽了一些mysql同步控制相关的话题, 我的意思是使用mysql的时候, 为了达到完美使用的目的, 必须配合高级语言的锁机制去实现, 使得我们开发人员要多操心一些东西.

这一节我就来说说redis的一个好处, 它让我们少操心了很多事情.

redis的最大特点是它是单线程架构, emmm, 这不是重点…

redis的最大特点是它提供了一些原子性的指令!

那么事情就变得简单了, 有一些简单的计数器场景下, 我们对计数+1操作, 都不需要去做任何的事务控制, 同步控制. 不同的客户端同时发送递增原子性指令,比如incr, 到达redis后, 被redis消息队列接受,随后被redis一个个依次执行! 最后我们得到的数据也不会出错

不过这个情况是符合直接使用这些原子性指令的时候,如果你中间参杂了其他非原子性指令, 比如你先get一个数据,再做增1. 那原子性结构就被破坏了, 数据一致性问题依旧会发生 请注意哦!

总结

其实说了半天, 我想说的就是redis提供了一些原子性指令,对于一些简单的计数器场景, 减少了我们需要的代码量去控制, 这些事情都由redis帮我们完成了

[注意]: 非原子性指令依旧需要进行同步控制, 请注意, 本文只针对redis的原子性指令而言, 节省了不少业务层代码量去控制

Live2d