redis消息队列mysql_redis使用消息队列的场合？

题主的问题描述的不是很清楚，看题主是刚学习Redis，那应该是想了解为什么并发插入数据下Redis的性能会比Mysql高，至于消息队列，应该是说Redis没有锁等待的问题，不知道是否理解正确，先按这个问题来解释下，若有出入，欢迎修正。

先来看看Redis和Mysql的数据存储，Mysql是需要落到磁盘的，而Redis的数据是写入内存即表示成功，至于持久化是异步刷到磁盘的(虽然可以同步刷到磁盘，但那样效率和Mysql没有多大差别)。内存的读写性能大概是磁盘的1-2个数量级，所以这里从本质上决定了Redis的读写性能高于Mysql。

再来看看Redis和Mysql的存储模型，Redis是Key-Value的，Mysql是关系型数据库，Key-Value的插入和查找基本都是O(1)的复杂度，而关系型数据库会涉及到索引的查找和插入，是对数级的复杂度(InnoDB，有索引)，但这个在InnoDB下并不是太大的问题，因为Mysql是多线程的，并且引入了MVCC(多版本并发控制)，插入的时候不会锁表，还能更好的利用多核，所以不会因为并发在插入时造成太大的性能问题。

然后看看楼主提出的并发问题，应该指的是Mysql使用MyISAM时，数据的插入都会锁表，但并不是死锁(死锁是互相持有对方所需资源等待对方释放)，只是这个时候针对单表的插入Mysql的多线程并不能发挥优势，所有的数据只能一条一条插入，所以相对于Redis，最终的性能差异在磁盘和算法本身的复杂度上。

最后说说题主说的Redis的消息队列，题主的意思应该是Redis的线程模型是单线程的，所有的命令都是在一个命令队列里，一个接着一个执行，并不能并发执行。这种模型的最大优势是编程简单，并不会为并发带来优势，相反，不能利用多核是其最大的弊病，这种模型基本都是利用NIO来解决并发问题。当然，Redis这样也就不会造成死锁，因为没有资源的竞争，但Mysql的死锁是可以通过良好的设计避免的，所以，消息队列并不是Redis性能高的原因。

谢谢，希望对大家有帮助。