Redis

1、消息如何保证100%的投递？ 2、幂等性概念 3、Confirm确认消息 4、Return返回消息 5、自定义消费者 消息 100% 的投递 消息如何保障 100%的投递成功？ 什么是生产端的可靠性投递？ u 保障消息的成功发出 u 保障MQ节点的成功接收 u 发送端收到MQ节点（Broker）确认应答 u 完善的消息进行补偿机制 BAT/TMD互联网大厂的解决方案： u 消息落库，对消息状态进行打标 u 消息的延迟投递，做二次确认，回调检查 幂等性概念 幂等性是什么？ u 我们可以借鉴数据库的乐观锁机制 u 比如我们执行一条更新库存的SQL语句 u Update t_repository set count = count -1,version = version + 1 where version = 1 u Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到） 消费端-幂等性保障 在海量订单产生的业务高峰期，如何避免消息的重复消费问题？ 消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息 业界主流的幂等性操作 唯一ID+指纹码机制，利用数据库主键去重 利用Redis的原子性去实现 唯一ID+指纹码 机制 唯一ID+指纹码机制，利用数据库主键去重 Select count(1) from T

文章目录 1. 什么是幂等性？ 1.1 消息队列的幂等性 1.2 模拟重试机制 1.2.1 生产者代码 1.2.2 消费者代码 1.2.3 消费者 application.yml 配置 2. 如何保证消息幂等性，不被重复消费？ 解决方法 1. 什么是幂等性？ 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。 HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴，正如编译器只能帮助检查语法错误一样，HTTP规范也没有办法通过消息格式等语法手段来定义它。 简之：一个请求，不管重复来多少次，结果是不会改变的。 1.1 消息队列的幂等性 如同HTTP方法的幂等性，消息队列同样会出现幂等性问题。 消费者在消费 MQ 中的消息时，MQ 已把消息发送给消费者，消费者在给 MQ 返回 ack 时网络中断，故 MQ 未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息；注意，RabbitMQ 这种消息重试(补偿)机制是默认的。 所以，MQ 消费者的幂等性问题，主要在于 MQ 的重试机制，因为网络原因或客户端延迟消费导致重复消费。 那么，如何合适选择重试机制？我们来看两种情况。 情况1： 消费者获取到消息后，调用第三方接口，但接口暂时无法访问

一、使用场景 　　我们在日常的开发中，经常会遇到查询数据列表的问题，有些数据是不经常变化的，如果想做一下优化，在提高查询的速度的同时减轻数据库的压力，那么redis缓存绝对是一个好的解决方案。 二、需求 　　假设有10000个请求，想达到第一次请求从数据库中获取，其他9999个请求从redis中获取这种效果。 三、代码实现 3.1、常规写法 public List<UsersDO> getAllUserWithNoPage2(){ try{ //序列化器，将key的值设置为字符串 RedisSerializer redisSerializer=new StringRedisSerializer(); redisTemplate.setKeySerializer(redisSerializer); //查缓存 List<UsersDO> list=(List<UsersDO>)redisTemplate.opsForValue().get("allUsers"); if(null==list){ UsersQuery query=new UsersQuery(); list=usersDOMapper.selectByExample(query); redisTemplate.opsForValue().set("allUsers", list); System.out

2018 年下半年以来，孙某（上海宏路数据技术股份有限公司副总经理）与苏某（北京亿量科技有限公司法定代表人）商议合作开展锁屏拉起广告业务（通过在用户手机上植入带有木马程序的 SDK，可控制手机在锁屏状态下自动在后台开启指定的 APP 广告），各自利用所在公司掌握的媒体流量资源、广告投放技术，实现流量变现。双方口头约定前者分得获利的 70%，后者分得获利的 30%，由后者将获利款项汇入前者指定的个人银行账户。后双方各自利用自身技术条件，共同进行研发调试。 期间，苏某指使韩某、刘某、赵某某、李某（均另案处理）共同参与研发调试带有木马程序的SDK，孙某指使马某某、麻某某（均另案处理）配合苏某提供优酷APP的接口以便于植入上述带有木马程序的SDK等相关技术对接工作。 截至案发，孙某、苏某、蔡某某等人非法控制包括绍兴越城被害人李某、陆某、陈某等人在内的手机合计 5593700 部。苏某通过锁屏拉起业务从广告主处获取广告费用合计人民币 330178 元，其中孙某分得人民币合计 231125 元，苏某分得人民币合计 99053 元。 2019 年 11 月 13 日，苏某在北京市朝阳区被警察抓获；同月 26 日，孙某、蔡某某在上海市虹口区被警察抓获。根据判决，苏某犯非法控制计算机信息系统罪，判处有期徒刑三年，缓刑四年，并处罚金人民币十二万元。 （来源：中国裁判文书网、云头条） 送两个技术全图

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）

感谢有你们 转眼马上就十月一了，听说今年的阅兵阵势非常强大，菜菜虽然身在北京，但是可能也目睹不了这个激动时刻了。自从2018年年底决定开始写公众号以来，几乎每个周末都在构思文章，撰写文章。关注公众号的老粉丝应该知道，菜菜的文章几乎都是技术类型，很少有职场感悟类型，有时候我也在想是否应该分享一下自己的职场感悟，毕竟纯技术类文章对于大家还是过于枯燥乏味。 经历了春夏秋冬的一个轮回，菜菜希望能带给大家一点收获。虽然一年来写的文章不像有的大佬那样多，但是我得承认每篇文章我确实在用心写，其实菜菜平时的工作比较多，所以也只能抽出周末的时间来写作，还望大家见谅。这一年我送了很多书，在菜菜粉丝群的用户应该知道，光是在群里就送了不止几十本，如果你想入群的话，可以联系菜菜微信申请入群。除了群内，大部分每周都有抽奖，具体可关注菜单=》福利部分。 说了这么多，今天菜菜想把以前的文章做一个总结，算是带自己和大家温故而知新吧，希望你们能有新的收获 0 1 算法与数据结构 程序猿修仙之路--算法之插入排序 程序员修仙之路--高性能排序多个文件 程序员修仙之路--把用户访问记录优化到极致 程序员修仙之路--设计一个实用的线程池 程序员修仙之路-数据结构之 CXO让我做一个计算器 程序猿修仙之路--数据结构之设计高性能访客记录系统 程序猿修仙之路--算法之快速排序到底有多快 程序猿修仙之路-

大多数情况下，我们都会通过请求-相应机制去操作redis。只用这种模式的一般的步骤是，先获得jedis实例，然后通过jedis的get/put方法与redis交互。由于redis是单线程的，下一次请求必须等待上一次请求执行完成后才能继续执行。然而使用Pipeline模式，客户端可以一次性的发送多个命令，无需等待服务端返回。这样就大大的减少了网络往返时间，提高了系统性能。 　　下面用一个例子测试这两种模式在效率上的差别： 　　 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 public class PiplineTest { private static int count = 10000 ; public static void main(String[] args){ useNormal(); usePipeline(); } public static void usePipeline(){ ShardedJedis jedis = getShardedJedis(); ShardedJedisPipeline pipeline = jedis.pipelined(); long

本文是《 Redis内部数据结构详解 》系列的第五篇。在本文中，我们介绍一个Redis内部数据结构——quicklist。Redis对外暴露的list数据类型，它底层实现所依赖的内部数据结构就是quicklist。 我们在讨论中还会涉及到两个Redis配置（在redis.conf中的ADVANCED CONFIG部分）： list-max-ziplist-size -2 list-compress-depth 0 我们在讨论中会详细解释这两个配置的含义。 注：本文讨论的quicklist实现基于Redis源码的3.2分支。 quicklist概述 Redis对外暴露的上层list数据类型，经常被用作队列使用。比如它支持的如下一些操作： lpush : 在左侧（即列表头部）插入数据。 rpop : 在右侧（即列表尾部）删除数据。 rpush : 在右侧（即列表尾部）插入数据。 lpop : 在左侧（即列表头部）删除数据。 这些操作都是O(1)时间复杂度的。 当然，list也支持在任意中间位置的存取操作，比如 lindex 和 linsert ，但它们都需要对list进行遍历，所以时间复杂度较高。 概况起来，list具有这样的一些特点：它是一个有序列表，便于在表的两端追加和删除数据，而对于中间位置的存取具有O(N)的时间复杂度。这不正是一个双向链表所具有的特点吗？