静态网站做等级保护,html5 网站布局应用教程,如何推广普通话,重庆网站建设网站建设我们平时习惯于使用 Rabbitmq 和 Kafka 作为消息队列中间件#xff0c;来给应用程序之间增加异步消息传递功能。这两个中间件都是专业的消息队列中间件#xff0c;特性之多超出了大多数人的理解能力。 使用过 Rabbitmq 的同学知道它使用起来有多复杂#xff0c;发消息之前要… 我们平时习惯于使用 Rabbitmq 和 Kafka 作为消息队列中间件来给应用程序之间增加异步消息传递功能。这两个中间件都是专业的消息队列中间件特性之多超出了大多数人的理解能力。 使用过 Rabbitmq 的同学知道它使用起来有多复杂发消息之前要创建 Exchange再创建 Queue还要将 Queue 和 Exchange 通过某种规则绑定起来发消息的时候要指定 routing-key还要控制头部信息。消费者在消费消息之前也要进行上面一系列的繁琐过程。但是绝大多数情况下虽然我们的消息队列只有一组消费者但还是需要经历上面这些繁琐的过程。 有了 Redis它就可以让我们解脱出来对于那些只有一组消费者的消息队列使用 Redis 就可以非常轻松的搞定。Redis 的消息队列不是专业的消息队列它没有非常多的高级特性没有 ack 保证如果对消息的可靠性有着极致的追求那么它就不适合使用。 异步消息队列 Redis 的 list(列表) 数据结构常用来作为异步消息队列使用使用rpush/lpush操作入队列使用lpop 和 rpop来出队列。 img markdown复制代码 rpush notify-queue apple banana pear(integer) 3 llen notify-queue(integer) 3 lpop notify-queueapple llen notify-queue(integer) 2 lpop notify-queuebanana llen notify-queue(integer) 1 lpop notify-queuepear llen notify-queue(integer) 0 lpop notify-queue(nil) 上面是 rpush 和 lpop 结合使用的例子。还可以使用 lpush 和 rpop 结合使用效果是一样的。这里不再赘述。 队列空了怎么办 客户端是通过队列的 pop 操作来获取消息然后进行处理。处理完了再接着获取消息再进行处理。如此循环往复这便是作为队列消费者的客户端的生命周期。 可是如果队列空了客户端就会陷入 pop 的死循环不停地 pop没有数据接着再 pop又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的 CPUredis 的 QPS 也会被拉高如果这样空轮询的客户端有几十来个Redis 的慢查询可能会显著增多。 通常我们使用 sleep 来解决这个问题让线程睡一会睡个 1s 钟就可以了。不但客户端的 CPU 能降下来Redis 的 QPS 也降下来了。 bash复制代码time.sleep(1) # python 睡 1sThread.sleep(1000) # java 睡 1s img 队列延迟 用上面睡眠的办法可以解决问题。但是有个小问题那就是睡眠会导致消息的延迟增大。如果只有 1 个消费者那么这个延迟就是 1s。如果有多个消费者这个延迟会有所下降因为每个消费者的睡觉时间是岔开来的。 有没有什么办法能显著降低延迟呢你当然可以很快想到那就把睡觉的时间缩短点。这种方式当然可以不过有没有更好的解决方案呢当然也有那就是 blpop/brpop。 这两个指令的前缀字符b代表的是blocking也就是阻塞读。 阻塞读在队列没有数据的时候会立即进入休眠状态一旦数据到来则立刻醒过来。消息的延迟几乎为零。用blpop/brpop替代前面的lpop/rpop就完美解决了上面的问题。 空闲连接自动断开 你以为上面的方案真的很完美么先别急着开心其实他还有个问题需要解决。 什么问题—— 空闲连接的问题。 如果线程一直阻塞在哪里Redis 的客户端连接就成了闲置连接闲置过久服务器一般会主动断开连接减少闲置资源占用。这个时候blpop/brpop会抛出异常来。 所以编写客户端消费者的时候要小心注意捕获异常还要重试。 锁冲突处理 上节课我们讲了分布式锁的问题但是没有提到客户端在处理请求时加锁没加成功怎么办。一般有 3 种策略来处理加锁失败 直接抛出异常通知用户稍后重试 sleep 一会再重试 将请求转移至延时队列过一会再试 直接抛出特定类型的异常 这种方式比较适合由用户直接发起的请求用户看到错误对话框后会先阅读对话框的内容再点击重试这样就可以起到人工延时的效果。如果考虑到用户体验可以由前端的代码替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃由用户决定是否重新发起新的请求。 sleep sleep 会阻塞当前的消息处理线程会导致队列的后续消息处理出现延迟。如果碰撞的比较频繁或者队列里消息比较多sleep 可能并不合适。如果因为个别死锁的 key 导致加锁不成功线程会彻底堵死导致后续消息永远得不到及时处理。 延时队列 这种方式比较适合异步消息处理将当前冲突的请求扔到另一个队列延后处理以避开冲突。 延时队列的实现 延时队列可以通过 Redis 的 zset(有序列表) 来实现。我们将消息序列化成一个字符串作为 zset 的value这个消息的到期处理时间作为score然后用多个线程轮询 zset 获取到期的任务进行处理多个线程是为了保障可用性万一挂了一个线程还有其它线程可以继续处理。因为有多个线程所以需要考虑并发争抢任务确保任务不能被多次执行。 py复制代码def delay(msg): msg.id str(uuid.uuid4()) # 保证 value 值唯一 value json.dumps(msg) retry_ts time.time() 5 # 5 秒后重试 redis.zadd(delay-queue, retry_ts, value)def loop(): while True: # 最多取 1 条 values redis.zrangebyscore(delay-queue, 0, time.time(), start0, num1) if not values: time.sleep(1) # 延时队列空的休息 1s continue value values[0] # 拿第一条也只有一条 success redis.zrem(delay-queue, value) # 从消息队列中移除该消息 if success: # 因为有多进程并发的可能最终只会有一个进程可以抢到消息 msg json.loads(value) handle_msg(msg) Redis 的 zrem 方法是多线程多进程争抢任务的关键它的返回值决定了当前实例有没有抢到任务因为 loop 方法可能会被多个线程、多个进程调用同一个任务可能会被多个进程线程抢到通过 zrem 来决定唯一的属主。 同时我们要注意一定要对 handle_msg 进行异常捕获避免因为个别任务处理问题导致循环异常退出。以下是 Java 版本的延时队列实现因为要使用到 Json 序列化所以还需要 fastjson 库的支持。 java复制代码import java.lang.reflect.Type;import java.util.Set;import java.util.UUID;import com.alibaba.fastjson.JSON;import com.alibaba.fastjson.TypeReference;import redis.clients.jedis.Jedis;public class RedisDelayingQueueT { static class TaskItemT { public String id; public T msg; } // fastjson 序列化对象中存在 generic 类型时需要使用 TypeReference private Type TaskType new TypeReferenceTaskItemT() { }.getType(); private Jedis jedis; private String queueKey; public RedisDelayingQueue(Jedis jedis, String queueKey) { this.jedis jedis; this.queueKey queueKey; } public void delay(T msg) { TaskItemT task new TaskItemT(); task.id UUID.randomUUID().toString(); // 分配唯一的 uuid task.msg msg; String s JSON.toJSONString(task); // fastjson 序列化 jedis.zadd(queueKey, System.currentTimeMillis() 5000, s); // 塞入延时队列 ,5s 后再试 } public void loop() { while (!Thread.interrupted()) { // 只取一条 SetString values jedis.zrangeByScore(queueKey, 0, System.currentTimeMillis(), 0, 1); if (values.isEmpty()) { try { Thread.sleep(500); // 歇会继续 } catch (InterruptedException e) { break; } continue; } String s values.iterator().next(); if (jedis.zrem(queueKey, s) 0) { // 抢到了 TaskItemT task JSON.parseObject(s, TaskType); // fastjson 反序列化 this.handleMsg(task.msg); } } } public void handleMsg(T msg) { System.out.println(msg); } public static void main(String[] args) { Jedis jedis new Jedis(); RedisDelayingQueueString queue new RedisDelayingQueue(jedis, q-demo); Thread producer new Thread() { public void run() { for (int i 0; i 10; i) { queue.delay(codehole i); } } }; Thread consumer new Thread() { public void run() { queue.loop(); } }; producer.start(); consumer.start(); try { producer.join(); Thread.sleep(6000); consumer.interrupt(); consumer.join(); } catch (InterruptedException e) { } }} 进一步优化 上面的算法中同一个任务可能会被多个进程取到之后再使用 zrem 进行争抢那些没抢到的进程都是白取了一次任务这是浪费。可以考虑使用 lua scripting 来优化一下这个逻辑将 zrangebyscore 和 zrem 一同挪到服务器端进行原子化操作这样多个进程之间争抢任务时就不会出现这种浪费了。 本文由 mdnice 多平台发布
