<强>序言:
复述是一个键值存储系统。和Memcached类似,它支持存储值的类型相对更多,包括字符串(字符串),列表(链表),设置集(合),zset(排序设置——有序集合)和散列(哈希类型)。这些数据类型都支持推/流行,添加/删除及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,复述,支持各种不同方式的排序。
"消息队列”是微软的消息处理技术,它在任何安装微软的Windows的计算机组合中,为任何应用程序提供消息处理和消息队列功能,无论这些计算机是否在同一个网络上或者是否同时联机。
"消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息,有些保存整个网络的重要信息,而有些只是发送和接收消息。
<强>复述,实现消息队列有两种形式:
广播订阅模式:基于复述的Pub/Sub机制,一旦有客户端往某个关键里面发布一个消息,所有订阅的客户端都会触发事件集群订阅模式:基于复述,双列表向+原子性+ BRPOP
<强>复述,消息队列时,当复述,宕机后,消息可能会丢失(也要看持久化的策略)。如果收消息方未有重发和验证机制,复述,内的数据会出现丢失。所以,使用复述的作为消息队列,通常是对于消息的准确性并非特别高的场景。
<>强如果绝对的保证数据最终一致性,保证消息百分百不丢,那么需要:
1。<强>写入时候要求启用事务处理,保证写一定成功。
2。<强>复述,配置成任何变更一定实时持久化,比如存储端是磁盘的话,每次变更马上同步写入磁盘,才算完成。复述是支持这种方式配置的,但是这么做会使它的内存数据库特性完全消失,性能变得十分低下。
3。<>强消费端也要实现事务方式,处理完成后,再回来真实删除消息。
4。<强>多线程或者多端同时并发处理,可以通过锁的方式来规避。
3 4的需求需要自己实现,可以一起考虑,用另外一个队列实现的方式也可以,但是更好的方式是在队列内部实现个计数器.hash格式的加个字段加数值,列表的先推一个数值打底,字符串的头上加个数值再加个分隔符,就可以做个简单计数器了,虽然土,胜在够实用。
除了特定的系统之外,一般不会要求这么强的一致性,实现倒不难,但是性能会很差很差。
银行类支付类业务会要求严格的事务一致性,而互联网类业务一般会用点取巧的方式,就是可以容忍极短时间内少量数据丢失的方式,换取更高性能。
比如上面的复述,处理,可以改为1000条数据变更的时候再真实落盘,即写入磁盘。那么极限情况下,如突然断电,存在可能丢失这1000条数据的风险。当然这种情况出现的概率也是很低的(远离蓝翔挖掘机?),所以大部分场景下可以接受。
以上就是复述,消息队列如何防止数据丢失的详细内容,更多请关注其它相关文章!
