新年10个Flag实现中~
访问量
1.9M
文章数
150
运行天
1147
一、和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磁盘复制【取值】节点列表  指定要备份到哪些节
123下一页