「时光不负，创作不停，本文正在参加2022年中总结征文大赛」 Reids是一个比较高级的开源key-value存储系统，采用ANSI C实现。其与memcached类似，但是支持持久化数据存储
入队操作
redis->connect(‘127.0.0.1’,6379);
KaTeX parse error: Undefined control sequence: [ at position 7: arr = \̲[̲ ['name' => …arr as v) { t h i s − > r e d i s − > r p u s h ( " m y l i s t " , j s o n _ e n c o d e ( this->redis->rpush("mylist", json_encode(this−>redis−>rpush("mylist",json_encode(v)); //加入队列值 } echo ‘队列已经加入完成’;
出队操作
i = 1; count; i++) { val = t h i s − > r e d i s − > L P O P ( ′ m y l i s t ′ ) ; v a r _ d u m p ( this->redis->LPOP('mylist'); var_dump(this−>redis−>LPOP( ′ mylist ′ );var_dump(val); echo “ ”; }
用redis的list当作队列可能存在的问题 1)redis崩溃的时候队列功能失效
2)如果入队端一直在塞数据，而出队端没有消费数据，或者是入队的频率大而多，出队端的消费频率慢会导致内存暴涨
3)Redis的队列也可以像rabbitmq那样即可以做消息的持久化，也可以不做消息的持久化。
当做持久话的时候，需要启动redis的dump数据的功能.暂时不建议开启持久化。
Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。应为dump时候，会影响性能，数据量小的时候还看不出来，当数据量达到百万级别，内存10g左右的时候，非常影响性能。
4)假如有多个消费者同时监听一个队列，其中一个出队了一个元素，另一个则获取不到该元素
5)Redis的队列应用场景是一对多或者一对一的关系，即有多个入队端，但是只有一个消费端(出队)
list方式的消息队列总结 实时性 实时性较好，可以通过brpop方式阻塞获取新消息，有高实时性；或者通过定时任务方式监听队列，存在较低延迟。 可靠性 综合可靠性一般，在点对点的消息推送机制下（lpush + rpop方案）不容易存在消息丢失，可以保证高可靠性。在其它场景可能存在并发安全性问题，但是可以通过加锁解决。存在事务失败问题，但是发生的概率较低。存在消息丢失问题，但是可以自己实现ack机制。 功能性 功能性一般，通过自己的额外扩展可以满足多种不同的消息队列功能，如多对多、发布订阅模式。 基于list的特点，可以推导出在两种常见场景下的实现方案：
针对生产者都采用lpush的方式推送数据，
针对消费者：
对实时性和可靠性要求高的情况，消费者使用brpop阻塞读取和消费数据 对实时性和可靠性要求不高的情况，但是推送数据量大，要求处理性能高，消费者使用定时任务+lrange+ltrim方式读取和消费数据
