centOs 流控，centos7静态ip
这篇文章给大家聊聊关于centOs 流控，以及centos7静态ip对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
RocketMQ 千锤百炼哈啰在分布式消息治理和微服务治理中的实践
简介：随着公司业务的不断发展，流量也在不断增长。我们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。
哈啰已进化为包括两轮出行（哈啰单车、哈啰助力车、哈啰电动车、小哈换电）、四轮出行（哈啰顺风车、全网叫车、哈啰打车）等的综合化移动出行平台，并向酒店、到店团购等众多本地生活化生态探索。
随着公司业务的不断发展，流量也在不断增长。我们发现生产中的一些重大事故，往往是被突发的流量冲跨的，对流量的治理和防护，保障系统高可用就尤为重要。
本文就哈啰在消息流量和微服务调用的治理中踩过的坑、积累的经验进行分享。
梁勇(老梁)，《 RocketMQ实战与进阶》专栏联合作者、参与了《 RocketMQ技术内幕》审稿工作。ArchSummit全球架构师大会讲师、QCon案例研习社讲师。
当前主要在后端中间件方向，在公众号【瓜农老梁】已陆续发表百余篇源码实战类文章，涵盖 RocketMQ系列、Kafka系列、GRPC系列、Nacosl系列、Sentinel系列、Java NIO系列。目前就职于哈啰出行，任职高级技术专家。
开始之前先聊聊治理这件事情，下面是老梁个人理解：
公司之前使用 RabbitMQ，下面在使用 RabbitMQ时的痛点，其中很多事故由于 RabbitMQ集群限流引起的。
曾经有这么一个故障，多个业务共用一个数据库。在一次晚高峰流量陡增，把数据库打挂了。
思考：无论消息还是服务都需要完善的治理措施
哪些是我们的关键指标，哪些是我们的次要指标，这是消息治理的首要问题。
设计目标
旨在屏蔽底层各个中间件（ RocketMQ/ Kafka）的复杂性，通过唯一标识动态路由消息。同时打造集资源管控、检索、监控、告警、巡检、容灾、可视化运维等一体化的消息治理平台，保障消息中间件平稳健康运行。
把复杂的问题搞简单，那是能耐。
极简统一 API
提供统一的 SDK封装了（ Kafka/ RocketMQ）两种消息中间件。
主题消费组自动创建不适合生产环境，自动创建会导致失控，不利于整个生命周期管理和集群稳定。需要对申请流程进行控制，但是应尽可能简单。例如：一次申请各个环境均生效、生成关联告警规则等。
监控客户端使用是否规范，找到合适的措施治理
场景一瞬时流量与集群的流控
假设现在集群 Tps有 1万，瞬时翻到 2万甚至更多，这种过度陡增的流量极有可能引发集群流控。针对这类场景需监控客户端的发送速度，在满足速度和陡增幅度阈值后将发送变的平缓一些。
场景二大消息与集群抖动
当客户端发送大消息时，例如：发送几百KB甚至几兆的消息，可能造成 IO时间过长与集群抖动。针对这类场景治理需监控发送消息的大小，我们采取通过事后巡检的方式识别出大消息的服务，推动使用同学压缩或重构，消息控制在 10KB以内。
场景三过低客户端版本
随着功能的迭代 SDK的版本也会升级，变更除了功能外还有可能引入风险。当使用过低的版本时一个是功能不能得到支持，另外一个是也可能存在安全隐患。为了解 SDK使用情况，可以采取将 SDK版本上报，通过巡检的方式推动使用同学升级。
场景四消费流量摘除和恢复
消费流量摘除和恢复通常有以下使用场景，第一个是发布应用时需要先摘流量，另外一个是问题定位时希望先把流量摘除掉再去排查。为了支持这种场景，需要在客户端监听摘除/恢复事件，将消费暂停和恢复。
场景五发送/消费耗时检测
发送/消费一条消息用了多久，通过监控耗时情况，巡检摸排出性能过低的应用，针对性推动改造达到提升性能的目的。
场景六提升排查定位效率
在排查问题时，往往需要检索发了什么消息、存在哪里、什么时候消费的等消息生命周期相关的内容。这部分可以通过 msgId在消息内部将生命周期串联起来。另外是通过在消息头部埋入 rpcId/ traceId类似链路标识，在一次请求中将消息串起来。
需要的监控信息
常用治理措施
监控主题消费组资源使用情况
场景一消费积压对业务的影响
有些业务场景对消费堆积很敏感，有些业务对积压不敏感，只要后面追上来消费掉即可。例如单车开锁是秒级的事情，而信息汇总相关的批处理场景对积压不敏感。通过采集消费积压指标，对满足阈值的应用采取实时告警的方式通知到应用负责的同学，让他们实时掌握消费情况。
场景二消费/发送速度的影响
发送/消费速度跌零告警？有些场景速度不能跌零，如果跌零意味着业务出现异常。通过采集速度指标，对满足阈值的应用实时告警。
场景三消费节点掉线
消费节点掉线需要通知给应用负责的同学，这类需要采集注册节点信息，当掉线时能实时触发告警通知。
场景四发送/消费不均衡
发送/消费的不均衡往往影响其性能。记得有一次咨询时有同学将发送消息的key设置成常量，默认按照 key进行 hash选择分区，所有的消息进入了一个分区里，这个性能是无论如何也上不来的。另外还要检测各个分区的消费积压情况，出现过度不均衡时触发实时告警通知。
需要的监控信息
常用治理措施
度量集群健康的核心指标有哪些？
场景一集群健康检测
集群健康检测回答一个问题：这个集群是不是好的。通过检测集群节点数量、集群中每个节点心跳、集群写入Tps水位、集群消费Tps水位都是在解决这个问题。
场景二集群的稳定性
集群流控往往体现出集群性能的不足，集群抖动也会引发客户端发送超时。通过采集集群中每个节点心跳耗时情况、集群写入Tps水位的变化率来掌握集群是否稳定。
场景三集群的高可用
高可用主要针对极端场景中导致某个可用区不可用、或者集群上某些主题和消费组异常需要有一些针对性的措施。例如：MQ可以通过同城跨可用区主从交叉部署、动态将主题和消费组迁移到灾备集群、多活等方式进行解决。
需要的监控信息
常用治理措施
如果说这些关键指标中哪一个最重要？我会选择集群中每个节点的心跳检测，即：响应时间（ RT），下面看看影响 RT可能哪些原因。
我们总会遇到坑，遇到就把它填了。
**
RocketMQ从节点、主节点频繁 CPU飙高，很明显的毛刺，很多次从节点直接挂掉了。
只有系统日志有错误提示
2020-03-16T17:56:07.505715+08:00 VECS0xxxx kernel:[]? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00 VECS0xxxx kernel: java: page allocation failure. order:0, mode:0x202020-03-16T17:56:07.505719+08:00 VECS0xxxx kernel: Pid: 12845, comm: java Not tainted 2.6.32-754.17.1.el6.x86_64#12020-03-16T17:56:07.505721+08:00 VECS0xxxx kernel: Call Trace:2020-03-16T17:56:07.505724+08:00 VECS0xxxx kernel:[]? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505726+08:00 VECS0xxxx kernel: []? dev_queue_xmit+0xd0/0x3602020-03-16T17:56:07.505729+08:00 VECS0xxxx kernel: []? ip_finish_output+0x192/0x3802020-03-16T17:56:07.505732+08:00 VECS0xxxx kernel: []?
各种调试系统参数只能减缓但是不能根除，依然毛刺超过 50%
将集群所有系统升级从 centos 6升级到 centos 7，内核版本也从从 2.6升级到 3.10，CPU毛刺消失。
RocketMQ社区版默认本支持 18个延迟级别，每个级别在设定的时间都被会消费者准确消费到。为此也专门测试过消费的间隔是不是准确，测试结果显示很准确。然而，如此准确的特性居然出问题了，接到业务同学报告线上某个集群延迟消息消费不到，诡异！
将" delayOffset.json"和" consumequeue/ SCHEDULE_TOPIC_XXXX"移到其他目录，相当于删除；逐台重启 broker节点。重启结束后，经过验证，延迟消息功能正常发送和消费。
哪些是我们的核心服务，哪些是我们的非核心服务，这是服务治理的首要问题
服务能应对突如其来的陡增流量，尤其保障核心服务的平稳运行。
根据用户和业务影响两个纬度来进行评估设定的，将应用分成了四个等级。
S1：核心产品，产生故障会引起外部用户无法使用或造成较大资损，比如主营业务核心链路，如单车、助力车开关锁、顺风车的发单和接单核心链路，以及其核心链路强依赖的应用。
S2:不直接影响交易，但关系到前台业务重要配置的管理与维护或业务后台处理的功能。
S3:服务故障对用户或核心产品逻辑影响非常小，且对主要业务没影响，或量较小的新业务；面向内部用户使用的重要工具，不直接影响业务，但相关管理功能对前台业务影响也较小。
S4:面向内部用户使用，不直接影响业务，或后续需要推动下线的系统。
S1服务是公司的核心服务，是重点保障的对象，需保障其不被非核心服务流量意外冲击。
**
**
CentOS 之小清新minicom使用
在 CentOS系统中，minicom是一个轻量级但功能强大的串口工具，尤其适合调试板卡 ARM SOC时没有网口的情况。让我们一起踏上这趟小清新之旅，了解如何轻松上手并充分利用 minicom。
步骤一：发现并识别串口设备
首先，确保你的 USB转串口设备已连接。通过输入 ls-l/dev/ttyUSB*，你会看到新出现的ttyUSB设备，这就是我们的串口标识。
步骤二：配置串口连接
启动 minicom命令 minicom-s，进入配置界面。按下'A'键，选择对应的 USB设备，然后选择'E'键调整波特率，通常设置为无流控。设置完毕后，按回车键退出配置模式。
设置默认配置并启动
为了方便下次快速连接，记得将刚才的设置保存为默认配置。退出 minicom，只需输入 CTRL+ A X。然后直接运行 minicom，你会按照刚才的默认配置顺利连接到串口。
灵活管理与控制
遇到 minicom被他人占用时，使用 ps-a查找进程号，执行 kill-9强制结束占用进程，轻松解决占用问题。例如，如果进程号为 12345，命令为 kill-9 12345。
告别繁琐，minicom带来的便捷
过去，我们可能需要在一台电脑上通过串口工具远程连接到有板卡的设备，这无疑增加了工作的复杂性。但在 CentOS中，minicom的出现就像一股清风，无需额外的电脑，只需在宿主机上运行，就可高效地进行串口调试。minicom的简洁界面和高效性能，无疑让这个过程变得更加优雅便捷。
