一、和Istio的融合问题1.1Istio的mTLS默认开启导致无法访问K8S服务在Istio1.4.x版本，MeshPolicy默认开启全局mTLS（values.global.mtls.enable=true），如果服务网格没有定义DestinationRule，那么就会使用mTLS。如果此时网格内的服务想要访问外部的K8S服务（比如数据库等，没有进入网格的K8S服务），istio会以为它是网格内的，仍然以mTLS建立连接，导致对端服务无法响应。因此，需要显式地设置Istio的DestinationRule，禁用掉mTLS：apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:mysql-1nam

前言长连接放到K8S之后，做性能测试就发现连接量上不去，在7~8W连接左右的时候，ELB的“波动队列”就开始暴增至1024，然后开始丢包。我一直有其他的工作要处理，这个排查又比较费时间，所以一直把这个事情搁置了。在迭代新版本的时候，发现连接量降至单个容器6W左右，反向优化最为致命…我的同事开始排查这个问题，最终找到是ELB的问题，记录一下他的思考过程，积累经验。一、问题描述在AWS的ELB（CLB）中，有一项监控指标叫做波动队列（SurgeQueue），长度最大为1024。波动队列的作用是，当后端服务器没有响应的时候，它会将请求包缓存起来，等服务器有响应了之后再把这些包慢慢消化掉，如果流量过大超过1024，则直接将包丢弃掉，避免在服务器处理能力有问题的时候遇到突增流量导致崩溃。在性能测试（P

一、M12简介Moquette0.12（以下简称M12）的订阅树实现在moquette-0.12/broker/src/main/java/io/moquette/broker/subscriptions，包括：订阅树版本 M10 M12  订阅树增删改查SubscriptionDirectory CTrieSubscriptionDirectory 订阅树 - CTrie 片段 Token Token 主题 Topic Topic 订阅信息 Subscription Subscription 普通节点 

一、M10简介Moquette0.10（以下简称M10）的订阅树实现在moquette-0.10/broker/src/main/java/io/moquette/spi/impl/subscriptions，包括：SubscriptionsDirectory：订阅树的增删改查Token：片段，由topicFilter按“/”分割而成的最小字符串单位Topic：主题/主题过滤器，包含一系列方法，比如比较主题和主题过滤器是否匹配Subscription：订阅信息，{clientId,topicFilter，qos，active}TreeNode：树节点查看源码的时候应该从SubscriptionsDirectory开始阅读。二、M10订阅树表示假设有如下订阅信息： 节点编号 

一、MQTT主题和主题过滤器匹配需求MQTT协议规定，客户端可以订阅（Subscribe）主题过滤器（TopicFilter），主题过滤器可能为：完全精确的主题过滤器。例如：abc/def/123含有单层通配符（+，SINGLE）的主题过滤器。例如：abc/+/123含有多层通配符（#，MULTI）的主题过滤器。例如：abc/#同时，客户端还可以向某个主题（Topic）发布（Publish）消息，比如abc/def/123，主题不能含有通配符。MQTTBroker需要查询有哪些客户端订阅了匹配这个主题的主题过滤器，并将消息发送给它们。例如下图所示情况：客户端X是发布者，将数据发布到主题"abc/def/123"；客户端A、B、C、D都是订阅者，但只有A、B、C订阅的主题过滤器和该主题匹配：A

前言在接触到MQTT之后，总是会有疑问，为什么用MQTT不用TCP长连接透传？看起来【TCP长连接+私有协议透传】和【MQTT+业务主题】似乎都能达到同样的目的，甚至用MQTT会使得设备端逻辑实现、APP端逻辑实现、云端架构实现更加复杂。那么为什么物联网还要使用MQTT协议呢？一、MQTT相比于TCP长连接的优势1、协议更标准MQTT是标准的RFC协议，相比于私有协议而言更加标准。好处在于：（1）协议非常完整，能够马上用于生产。各端实现同一套协议之后，就能进行通信；私有协议还需要进行大量的验证，看有无缺陷或欠考虑的地方等。（2）协议的标准化带来大量的开源组件，降低开发难度。随着物联网+5G生态越来越好，开源组件越来越多，可以减少重复编码量。（3）标准协议利于第三方接入。当第三方设备、平台想要

前言百度IoT的Broker设计我特别想参考的但是技术能力和时间不够去实现……网上只有一篇百度工程师的总结《共享行业的分布式MQTT设计》，这里将围绕这篇文章去讲解。一、Broker集群架构单机版MQTTBroker有连接数量和并发处理能力的限制，因此分布式必不可少。百度IoT采用的AkkaCluster来做集群管理，每个节点对等，不存在像Mosquitto这种用一台机器“桥接”做分布式产生的单点故障隐患。每个节点监听MemberUp、MemberDown、MemberUnreachable、ClusterMemberState等事件来感知其他节点的上下线，用AkkaActor实现节点间的消息通信。二、Broker服务框架百度Broker抽象了很多服务包括：（1）Authentication

前言基于EMQ2.3.11。Mnesia是分布式电信数据库管理系统，有以下特性：DBMS查询语言数据持久性：表是持久化到存储的集群复制：表可以在多个节点上复制原子事务：支持事务透明：对编程来说是透明的实时数据搜索：查询速度很快一、Mnesia表的创建参数1、type表类型【取值】set：唯一键值，1:1，一个键一条记录ordered_set：唯一键值，1:1，带排序bag：1:n，一个键可以映射很多条记录2、record_name记录名称【取值】记录名所有表中的记录都必须是同一个记录的实例3、ram_copies内存复制【取值】节点列表可以指定要备份到哪些节点的内存中去，不保证事务更新。可以定时刷盘。4、disc_copies磁盘复制【取值】节点列表  指定要备份到哪些节