centos 发送消息(centos官网)

本篇文章给大家谈谈centos 发送消息，以及centos官网对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。

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系统常规初始化操作详解

环境准备：

1）设置本地国际化语言为en_US.UTF-8

[root@c58~]#sed-i's/^\(LANG=\).*$/\1en_US.UTF-8/'/etc/sysconfig/i18n

[root@c58~]#cat/etc/sysconfig/i18n

LANG=en_US.UTF-8

[root@c58~]#LANG=en_US.UTF-8

2）更新系统软件包

备份默认yum源：

find/etc/yum.repos.d-name'*.repo'-execmv{}{}.bak\;

添加163yum源：

redhat5或centos5：

wget

redhat6或centos6

wget

添加epel yum源：

redhat5.x 32bit:

rpm-ivh

redhat5.x 64bit:

rpm-ivh

redhat6.x 32bit:

rpm-ivh

redhat6.x 64bit:

rpm-ivh

更新证书：

yum-yupgradeca-certificates--disablerepo=epel

更新系统所有软件包：

yumcleanallyummakecacheyum-yupgrade

下文以redhat5/centos5为例

一、服务最小化原则

关闭所有开机自启动服务，仅开启sshd、crond、network、iptables、syslog（redhat5）、rsyslog（redhat6），然后在此基础上按需添加需要开机启动的服务。

1）关闭所有开机自启动服务

[root@c58~]#foriin`chkconfig--list|awk'{if($1~/^$/){exit0;}else{print$1}}'`;dochkconfig$ioff;done

2）开启基础服务

[root@c58~]#foriinsshdnetworksyslogcrondiptables;dochkconfig$ion;done

3）查看开启的服务

[root@c58~]#chkconfig--list|grep'3:on'

crond0:off1:off2:on3:on4:on5:on6:off

iptables0:off1:off2:on3:on4:on5:on6:off

network0:off1:off2:on3:on4:on5:on6:off

sshd0:off1:off2:on3:on4:on5:on6:off

syslog0:off1:off2:on3:on4:on5:on6:off

二、用户登录限制

1）禁止使用root用户使用远程ssh

[root@c58~]#cd/etc/ssh

[root@c58ssh]#cpsshd_configsshd_config~

[root@c58ssh]#sed-i's/#\(PermitRootLogin\)yes/\1no/'sshd_config

[root@c58ssh]#grep'PermitRoot'/etc/ssh/sshd_config

PermitRootLoginno

2）禁用登录提示信息

[root@c58ssh]#/etc/motd

3）修改ssh的默认监听端口（tcp：22）

#这里修改为tcp的11983端口

[root@c58ssh]#sed-i's/#\(Port\)22/\11983/'sshd_config

[root@c58ssh]#grep'Port'sshd_config

Port11983

4）只允许指定的ip可以ssh(可选)

方法1（使用tcpwrapper）：

#只允许192.168.124.0网段的ip使用ssh

echosshd:192.168.124.0/255.255.255.0/etc/hosts.allow

echosshd:ALL/etc/hosts.deny

方法2（使用iptables）：

#注意，远程操作时需留心，以免把自己也拒绝而导致无法远程连接。如只允许192.168.1.0网段的所有ip进行ssh，其他所有ip都拒绝#先允许自己的ip，以防被后面的操作误伤

iptables-IINPUT-s10.0.0.1-ptcp--dport22-jACCEPT

#允许192.168.1.0网段

iptables-I2INPUT-s192.168.1.0/24-ptcp--dport22-jACCEPT

#拒绝所有

iptables-I3INPUT-ptcp--dport22-jDROP

#保存iptables的设置：

cp/etc/sysconfig/iptables/etc/sysconfig/iptables~

iptables-save/etc/sysconfig/iptables

最后，重启sshd服务使上面配置生效（不用担心重启时已打开的远程终端连接会断开，重启只会对新开的终端生效）

[root@c58ssh]#/etc/init.d/sshdrestart

Stoppingsshd:[OK]

Startingsshd:[OK]

三、用户及命令权限最小化

创建一个普通用户tom，将其加入sudo组，该用户作为系统管理员

groupaddsudo#创建sudo组

useradd-Gsudotom#创建tom用户，加入sudo组

passwdtom#设置tom用户的登陆密码

修改sudo配置文件，授权sudo组的用户可以以root身份执行所有命令（可以针对不同用户授予不同的命令执行权限，这里允许执行所有命令，生产环境中系统管理员应该按需为用户分配尽可能少的可执行命令，以实现权限最少化），用户执行的所有sudo操作都将记录在/var/log/sudo.log中，以便日后的安全事件排查。执行命令如下：

[root@cloud~]#cat/etc/sudoersEOF

%sudoALL=(root)ALL

Defaultslogfile=/var/log/sudo.log

EOF

[root@cloud~]#visudo-c

[root@cloud~]#echolocal2.debug/var/log/sudo.log/etc/syslog.conf

[root@cloud~]#/etc/init.d/syslogrestart

注：visudo-c命令用于检查/etc/sudoers文件的语法正确性

四、内核安全参数设置

vim/etc/sysctl.conf#添加如下内容：

#关闭对ping包的响应(可选，一般不建议，因为不方便网络故障时的排查)

net.ipv4.icmp_echo_ignore_all=1

#关闭对广播ping的响应

net.ipv4.icmp_echo_ignore_broadcasts=1

#开启syncookie用于防范synflood攻击，当出现syn等待队列溢出时（syn数量超过tcp_max_syn_backlog的设置值），启用cookie来处理，server在回复syn_ack前会先请求client回复一个序列号，该序列号中要求包含原先syn包中的信息，如果序列号不正确，则server端会忽略此syn连接。

net.ipv4.tcp_syncookies=1

#设置sync_ack的最大重传次数，默认值为5，范围0-255，重传5次的时间大约为180s

net.ipv4.tcp_synack_retries=3

#设置当keepalive打开的情况下，keepalive消息的发送间隔，默认为2小时(由于目前网络攻击等因素,造成了利用这个进行的攻击很频繁,如果两边建立了连接，然后不发送任何数据或者rst/fin消息,那么持续的时间就是2小时,成就了空连接攻击，tcp_keepalive_time就是预防此情形的.）

net.ipv4.tcp_keepalive_time=1200

保存退出后，执行sysctl-p命令将以上设置加载到内核使其立刻生效

五、内核性能相关参数设置（可选）

vim/etc/sysctl.conf#添加如下内容：

#设置syn等待队列的长度，对于内存大于128M的机器，默认值是1024，在并发请求较大时，可以调大该值

net.ipv4.tcp_max_syn_backlog

#开启timewait重用。允许将time_waitsocket重新用于新的tcp连接

net.ipv4.tcp_tw_reuse=1

#开启tcp连接中time_waitsocket的快速回收

net.ipv4.tcp_tw_recycle=1

#TCP发送keepalive探测以确定该连接已经断开的次数，默认值为9

net.ipv4.tcp_keepalive_probes=5

#指定探测消息发送的频率，该值乘以tcp_keepalive_probes就可以得到从开始探测到连接被删除所需的时间。默认值为75，也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)

net.ipv4.tcp_keepalive_intvl=15

#表示系统同时保持TIME_WAITsocket的最大数量，如果超过这个数字，TIME_WAIT套接字将立刻被清除并输出警告信息。默认为180000，改为5000.对于squid服务器来说，此参数可以控制TIME_WAIT套接字的最大数量，避免squid服务器被大量的TIME_WAITsocket拖死。

net.ipv4.tcp_max_tw_buckets=5000

#表示向外连接的端口范围。默认值很小：32768~61000，改为1024~65000

net.ipv4.ip_local_port_range=102465000

保存退出后，执行sysctl-p命令将以上设置加载到内核使其立刻生效

centos7中安装zookpeer和kafka(单机)

在CentOS 7服务器上安装Zookeeper和Kafka（单机模式）的过程如下：

首先，从官方网站下载Zookeeper和Kafka的压缩包。你可以选择官方提供的版本，或者从可信的第三方资源下载。

将下载的压缩包解压到服务器上的特定目录中，并创建一个用于存放压缩包的文件夹。例如：

新建一个名为`test`的文件夹。

安装Zookeeper的步骤如下：

1.将解压后的Zookeeper文件夹重命名为`zk`，并移动到`/usr/local/`目录下。

2.切换到`/usr/local/zk/conf/`目录下，复制一个`zoo_sample.cfg`文件并将其重命名为`zoo.cfg`。

3.使用文本编辑器（如vi）打开`zoo.cfg`文件，并修改`datadir`参数为`/usr/local/zk/data`。

4.在`zk`目录下创建`data`文件夹。

5.通过`/etc/profile`文件配置环境变量。添加`java_home`和`zk_home`的路径，将`zk`的`bin`目录路径添加到`path`中。

6.使环境变量生效，执行`source/etc/profile`。

7.进入`/usr/local/zk/bin/`目录，启动Zookeeper服务器：`zkServer.sh start`。

检查Zookeeper状态，确保其显示为`standalone`。

执行`zkServer.sh start`、`zkServer.sh stop`、`zkServer.sh restart`和`zkServer.sh status`，分别启动、停止、重启和查看当前节点状态。

接下来安装Kafka：

1.将Kafka压缩包解压到服务器上。

2.将解压后的Kafka文件夹移动到`/usr/local/`目录下。

3.切换到`/usr/local/kafka/config/`目录下，使用文本编辑器修改`server.properties`文件。

4.将`log.dirs`参数设置为`/usr/local/kafka/data/kafka-logs`，将`connect`中的`localhost`替换为服务器IP地址，修改`advertised.listeners`参数为`PLAINTEXT:// xx.xx.xx.xxx:9092`（`xx`代表你的服务器IP）。

5.常规模式下启动Kafka：`./kafka-server-start.sh../config/server.properties&`。

关闭Kafka：`./kafka-server-stop.sh`。

使用进程守护模式启动Kafka：`nohup./kafka-server-start.sh config/server.properties>/dev/null 2>&1&`。

如果在安装过程中遇到错误，可以尝试调整Kafka的启动内存大小，修改`KAFKA_HEAP_OPTS`环境变量为`-Xmx512M-Xms512M`。

创建一个Kafka主题：在Kafka的`bin`目录下执行`./kafka-topics.sh--create--zookeeper 127.0.0.1:2181--partitions 1--replication-factor 1--topic test`。

使用生产者向Kafka发送消息：`./kafka-console-producer.sh--broker-list 127.0.0.1:9092--topic test`。

使用消费者消费消息：在另一个终端窗口中执行`./kafka-console-consumer.sh--broker-list 127.0.0.1:9092--topic test`。

如果在使用消费者时遇到问题，可以尝试使用`./kafka-console-consumer.sh--bootstrap-server 127.0.0.1:9092--topic test`。

在CentOS 7中关闭防火墙：执行`systemctl stop firewalld.service`。

最后，确保将Kafka的`9092`端口添加到安全组中，以允许外部访问。