Redis

MQTT 全称 MQ Telemetry Transport 消息队列遥测传输协议 IBM 1994开发 MQTT v3.1.1 第4版 OASIS标准 1 to 0/1/N 简介 MQTT是一个TCP服务端，称为broker。 通过这个broker服务，我们可以作为发布者，发送一条主题消息给broker，然后其他订阅者通过消息订阅机制获得broker的主题消息推送。我们也可以作为订阅者，订阅其他发布者的主题消息。 对比MQ 消息队列存储消息，直到它们被消耗 消息队列中只有一个消费者处理消息，MQTT中订阅主题的每个订阅者都会收到消息 消息队列要提前并明确创建，MQTT中可以随时实时创建 议题 自动重连 Automatic Reconnect 离线缓存 Offline Buffering 消息持久化 Message Persistence 高可用 High Availability 安全 SSL/TLS websocket支持 连接 建立 broker开启一个host的TCP 1883端口 客户端连接Broker 如果是重连，需要带上上次ClientID 如果不是重连，可以指定CleanSession是否清空之前会话 可以指定两端之间心跳维持时间 服务端根据参数，重用或开启会话Session，绑定ClientID 一个会话，可以服务多个TCP连接，取决于是否CleanSession

最近频繁地在跟实习生候选人打交道，每次新接触一个候选人，都要花上一定的时间去介绍我们团队，候选人问的最多的一个问题就是「中间件部门一般是干嘛的？」，恰好我之前也接触过一些想从事中间件开发的小伙伴，问过我「现在转行做中间件开发还来得及吗？」诸如此类的问题，索性就写一篇文章，聊聊我个人这些年做中间件开发的感受吧。 什么是中间件开发？ 我大四实习时，在一个 20 多人的软件开发团队第一次接触了中间件，当时项目的架构师引入了微博开源的 RPC 框架 Motan，借助于这个框架，我们迅速构建起了一个基于微服务架构的内部电商系统。接着在项目中，由于业务需求，我们又引入了 ActiveMQ...在这个阶段，我已经在使用中间件了，但似乎没有接触到中间件开发，更多的是使用层面上的接触。 我毕业后的第一份工作，公司有几百号研发，当时的 leader 看我对中间件比较感兴趣，有意把我分配在了基础架构团队，我第一次真正意义上成为了一名”中间件研发“，平时主要的工作，是基于开源的 Kong 和 Dubbo，进行一些内部的改造，以提供给业务团队更好地使用。这个阶段，做的事还是比较杂的，业务团队对某些中间件有定制化的需求，都需要去了解这个中间件，熟悉源码。这段时间，也是我成长最快的一个时期，我是在这个期间学会了 Docker、Neo4j、Kong 等以前从来没接触过的技术，并且更加深入地了解 Dubbo 这类

前言 一般单机或者单数据库的项目可能规模比较小，适应的场景也比较有限，平台的访问量和业务量都较小，业务ID的生成方式比较原始但是够用，它并没有给这样的系统带来问题和瓶颈，所以这种情况下我们并没有对此给予太多的关注。但是对于大厂的那种大规模复杂业务、分布式高并发的应用场景，显然这种ID的生成方式不会像小项目一样仅仅依靠简单的数据自增序列来完成，而且在分布式环境下这种方式已经无法满足业务的需求，不仅无法完成业务能力，业务ID生成的速度或者重复问题可能给系统带来严重的故障。所以这一次，我们看看大厂都是怎么分析和解决这种ID生成问题的，同时，我也将我之前使用过的方式拿出来对比，看看有什么问题，从中能够得到什么启发。 分布式ID的生成特性 在分析之前，我们先明确一下业务ID的生成特性，在此特性的基础上，我们能够对下面的这几种生成方式有更加深刻的认识和感悟。 全局唯一 ，这是基本要求，不能出现重复。 数字类型，趋势递增 ，后面的ID必须比前面的大，这是从MySQL存储引擎来考虑的，需要保证写入数据的性能。 长度短 ，能够提高查询效率，这也是从MySQL数据库规范出发的，尤其是ID作为主键时。 信息安全 ，如果ID连续生成，势必会泄露业务信息，甚至可能被猜出，所以需要无规则不规则。 高可用低延时 ，ID生成快，能够扛住高并发，延时足够低不至于成为业务瓶颈。 分布式ID的几种生成办法

redis使用watch完成秒杀抢购功能： 使用redis中两个key完成秒杀抢购功能，mywatchkey用于存储抢购数量和mywatchlist用户存储抢购列表。 它的优点如下： 1. 首先选用内存数据库来抢购速度极快。 2. 速度快并发自然没不是问题。 3. 使用悲观锁，会迅速增加系统资源。 4. 比队列强的多，队列会使你的内存数据库资源瞬间爆棚。 5. 使用乐观锁，达到综合需求。 我觉得以下代码肯定是你想要的。 <?php header( "content-type:text/html;charset=utf-8"); $redis = new redis(); $result = $redis->connect( '10.10.10.119', 6379); $mywatchkey = $redis->get( "mywatchkey"); $rob_total = 100; //抢购数量 if( $mywatchkey< $rob_total){ $redis->watch( "mywatchkey"); $redis->multi(); //设置延迟，方便测试效果。 sleep(5); //插入抢购数据 $redis->hSet( "mywatchlist", "user_id_".mt_rand(1, 9999),time()); $redis->set(

今天来分享一下Redis几道常见的面试题： 如何解决缓存雪崩？ 如何解决缓存穿透？ 如何保证缓存与数据库双写时一致的问题？ 一、缓存雪崩 1.1 什么是缓存雪崩？ 首先我们先来回答一下我们为什么要用缓存(Redis)： 1、提高性能能：缓存查询是纯内存访问，而硬盘是磁盘访问，因此缓存查询速度比数据库查询速度快 2、提高并发能力：缓存分组了部分请求，支持更高的并发 现在有个问题， 如果我们的缓存挂掉了，这意味着我们的全部请求都跑去数据库了 。 我们都知道Redis不可能把所有的数据都缓存起来( 内存昂贵且有限 )，所以Redis需要对数据设置过期时间，将已经过期的键值对删除，它采用的是惰性删除+定期删除两种策略对过期键删除。 如果缓存数据 设置的过期时间是相同 的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存 同时失效 ，全部请求到数据库中。 这就是缓存雪崩 ： Redis挂掉了，请求全部走数据库。 对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。 缓存雪崩如果发生了，很可能就把我们的数据库 搞垮 ，导致整个服务瘫痪！ 1.2 如何解决缓存雪崩？ 对于“对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。”这种情况，非常好解决： 解决方法：在缓存的时候给过期时间加上一个 随机值 ，这样就会大幅度的