细说Redis监控和告警

对于任何应用服务和组件,都需要一套完善可靠谱监控方案。
尤其redis这类敏感的纯内存、高并发和低延时的服务,一套完善的监控告警方案,是精细化运营的前提。
本文分几节,细说Redis的监控和告警:
1.Redis监控告警的价值
2.Redis监控的数据采集
3.Redis告警策略
4.基于Open Falcon的Redis监控告警方案


Redis监控告警的价值

Redis监控告警的价值对每个角色都不同,重要的几个方面:

  • redis故障快速通知,定位故障点;对于DBA,redis的可用性和性能故障需快速发现和定位解决。

  • 分析redis故障的Root cause

  • redis容量规划和性能管理

  • redis硬件资源利用率和成本

redis故障快速发现,定位故障点和解决故障

当redis出现故障时,DBA应在尽可能短时间内发现告警;如果故障对服务是有损的(如大面积网络故障或程序BUG),需立即通知SRE和RD启用故障预案(如切换机房或启用emergency switch)止损。
如果没完善监控告警;假设由RD发现服务故障,再排查整体服务调用链去定位;甚于用户发现用问题,通过客服投诉,再排查到redis故障的问题;整个redis故障的发现、定位和解决时间被拉长,把一个原本的小故障被”无限”放大。

分析redis故障的Root cause

任何一个故障和性能问题,其根本“诱因”往往只有一个,称为这个故障的Root cause。
一个故障从DBA发现、止损、分析定位、解决和以后规避措施;最重要一环就是DBA通过各种问题表象,层层分析到Root cause;找到问题的根据原因,才能根治这类问题,避免再次发生。
完善的redis监控数据,是我们分析root cause的基础和证据。

备注:Troubleshtooing定位Root cause,就像医生通过病人的病历和检查报告找到“真正的病灶”,让病人康复和少受苦,一样有意思和复杂;或像刑警通过案件的证据分析和推理,寻找那个唯一的真相,一样惊心动魄。(快看DBA又在吹牛了),其实在大型商业系统中,一次故障轻松就达直接损失数十万(间接损失更大),那“抓住元凶”,避免它再次“作案”,同样是“破案”。

问题表现是综合情的,一般可能性较复杂,这里举2个例子:

  • 服务调用Redis响应时间变大的性能总是;可能网络问题,redis慢查询,redis QPS增高达到性能瓶颈,redis fork阻塞和请求排队,redis使用swap, cpu达到饱和(单核idle过低),aof fsync阻塞,网络进出口资源饱和等等

  • redis使用内存突然增长,快达到maxmemory; 可能其个大键写入,键个数增长,某类键平均长度突增,fork COW, 客户端输入/输出缓冲区,lua程序占用等等

Root cause是要直观的监控数据和证据,而非有技术支撑的推理分析。

  • redis响应抖动,分析定位root casue是bgsave时fork导致阻塞200ms的例子。而不是分析推理:redis进程rss达30gb,响应抖动时应该有同步,fork子进程时,页表拷贝时要阻塞父进程,估计页表大小xx,再根据内存copy连续1m数据要xx 纳秒,分析出可能fork阻塞导致的。(要的不是这种分析)

    说明:粮厂有个习惯,在分析root cause尽量能拿到直观证据。因为一旦引入推理步骤,每一步的推理结果都可能出现偏差,最终可能给出错误root cause. “元凶”又逃过一劫,它下次作案估计就会更大。所以建议任何小的故障或抖动,至少从个人或小组内部,深入分析找到root cause;这样个人或组织都会成长快; 形成良好的氛围。

Redis容量规划和性能管理

通过分析redis资源使用和性能指标的监控历史趋势数据;对集群进行合理扩容(Scale-out)、缩容(Scale-back);对性能瓶颈优化处理等。
Redis资源使用饱和度监控,设置合理阀值;
一些常用容量指标:redis内存使用比例,swap使用,cpu单核的饱和度等;当资源使用容量预警时,能及时扩容,避免因资源使用过载,导致故障。
另一方面,如果资源利用率持续过低,及时通知业务,并进行redis集群缩容处理,避免资源浪费。
进一步,容器化管理redis后,根据监控数据,系统能自动地弹性扩容和缩容。

Redis性能监控管理,及时发现性能瓶颈,进行优化或扩容,把问题扼杀在”萌芽期“,避免它”进化“成故障。

Redis硬件资源利用率和成本

从老板角度来看,最关心的是成本和资源利用率是否达标。
如果资源不达标,就得推进资源优化整合;提高硬件利用率,减少资源浪费。砍预算,减成本。
资源利用率是否达标的数据,都是通过监控系统采集的数据。

这一小节,扯了这么多; 只是强调redis不是只有一个端口存活监控就可以了。
下面进入主题,怎么采集redsis监控数。

老板曾说:监控告警和数据备份,是对DBA和SRE最基础也是最高的要求;
当服务和存储达到产品规模后,可认为“无监控,不服务;无备份,不存储”。

Redis监控数据采集

redis监控的数据采集,数据采集1分钟一次,分为下面几个方面:

  • 服务器系统数据采集

  • Redis Server数据采集

  • Redis响应时间数据采集

  • Redis监控Screen

服务器系统监控数据采集

服务器系统的数据采集,这部分包含数百个指标. 采集方式现在监控平台自带的agent都会支持
如Zabbix和Open Falcon等,这里就不介绍采集方法。

我们从redis使用资源的特性,分析各个子系统的重要监控指标。

服务器存活监控

  • ping监控告警

CPU

  • 平均负载(Load Average): 综合负载指标(暂且归类cpu子系统),当系统的子系统出现过度使用时,平均负载会升高。可说明redis的处理性能下降(平均响应时间变长、吞吐量降低)。

  • CPU整体利用率或饱和度(cpu.busy): redis在高并发或时间复杂度高的指令,cpu整体资源饱和,导致redis性能下降,请求堆积。

  • CPU单核饱和度(cpu.core.idle/core=0): redis是单进程模式,常规情况只使用一个cpu core, 单某个实例出现cpu性能瓶颈,导致性能故障,但系统一般24线程的cpu饱和度却很低。所以监控cpu单核心利用率也同样重样。

  • CPU上下文切换数(cpu.switches):context swith过高xxxxxx

内存和swap

  • 系统内存余量大小(mem.memfree):redis是纯内存系统,系统内存必须保有足够余量,避免出现OOM,导致redis进程被杀,或使用swap导致redis性能骤降。

  • 系统swap使用量大小(mem.swapused):redis的”热数据“只要进入swap,redis处理性能就会骤降; 不管swap分区的是否是SSD介质。OS对swap的使用材质还是disk store. 这也是作者早期redis实现VM,后来又放弃的原因。

说明:系统内存余量合理,给各种缓冲区,fork cow足够的内存空间。
另一个问题:我的系统使用Redis缓存集群,”不怕挂,就怕慢“,或redis集群高可用做得厉害;这样redis的服务器是否能关闭swap呢?

磁盘

  • 磁盘分区的使用率(df.bytes.used.percent):磁盘空间使用率监控告警,确保有足磁盘空间用AOF/RDB, 日志文件存储。不过 redis服务器一般很少出现磁盘容量问题

  • 磁盘IOPS的饱和度(disk.io.util):如果有AOF持久化时,要注意这类情况。如果AOF持久化,每秒sync有堆积,可能导致写入stall的情况。 另外磁盘顺序吞吐量还是很重要,太低会导致复制同步RDB时,拉长同步RDB时间。(期待diskless replication)

网络

  • 网络吞吐量饱和度(net.if.out.bytes/net.if.in.bytes):如果服务器是千兆网卡(Speed: 1000Mb/s),单机多实例情况,有异常的大key容量导致网卡流量打滿。redis整体服务等量下降,苦于出现故障切换。

  • 丢包率:Redis服务响应质量受影响

Redis Server监控数据采集

通过redis实例的状态数据采集,采集监控数据的命令
ping,info all, slowlog get/len/reset/cluster info/config get

Redis存活监控

  • redis存活监控(redis_alive):redis本地监控agent使用ping,如果指定时间返回PONG表示存活,否则redis不能响应请求,可能阻塞或死亡。

  • redis uptime监控(redis_uptime):uptime_in_seconds

Redis 连接数监控

  • 连接个数(connected_clients):客户端连接个数,如果连接数过高,影响redis吞吐量。常规建议不要超过5000.参考官方benchmarks

  • 连接数使用率(connected_clients_pct): 连接数使用百分比,通过(connected_clients/macclients)计算;如果达到1,redis开始拒绝新连接创建。

    1

    2

    3

    127.0.0.1:6380> set mykey myvalue

    (error) ERR max number of clients reached

    127.0.0.1:6380>

  • 拒绝的连接个数(rejected_connections): redis连接个数达到maxclients限制,拒绝新连接的个数。

  • 新创建连接个数(total_connections_received): 如果新创建连接过多,过度地创建和销毁连接对性能有影响,说明短连接严重或连接池使用有问题,需调研代码的连接设置。

  • list阻塞调用被阻塞的连接个数(blocked_clients): BLPOP这类命令没使用过,如果监控数据大于0,还是建议排查原因。

Redis内存监控

  • redis分配的内存大小(used_memory): redis真实使用内存,不包含内存碎片;单实例的内存大小不建议过大,常规10~20GB以内。

  • redis内存使用比例(used_memory_pct): 已分配内存的百分比,通过(used_memory/maxmemory)计算;对于redis存储场景会比较关注,未设置淘汰策略(maxmemory_policy)的,达到maxmemory限制不能写入数据。

    1

    2

    3

    127.0.0.1:6380> set mykey myvalue

    (error) OOM command not allowed when used memory > 'maxmemory'.

    127.0.0.1:6380>

  • redis进程使用内存大小(used_memory_rss): 进程实际使用的物理内存大小,包含内存碎片;如果rss过大导致内部碎片大,内存资源浪费,和fork的耗时和cow内存都会增大。

  • redis内存碎片率(mem_fragmentation_ratio): 表示(used_memory_rss/used_memory),碎片率过大,导致内存资源浪费;

    说明:
    1、如果内存使用很小时,mem_fragmentation_ratio可以远大于1的情况,这个告警值不好设置,需参考used_memory大小。
    2、如果mem_fragmentation_ratio小于1,表示redis已使用swap分区

Redis综合性能监控

Redis Keyspace

redis键空间的状态监控

  • 键个数(keys): redis实例包含的键个数。建议控制在1kw内;单实例键个数过大,可能导致过期键的回收不及时。

  • 设置有生存时间的键个数(keys_expires): 是纯缓存或业务的过期长,都建议对键设置TTL; 避免业务的死键问题. (expires字段)

  • 估算设置生存时间键的平均寿命(avg_ttl): redis会抽样估算实例中设置TTL键的平均时长,单位毫秒。如果无TTL键或在Slave则avg_ttl一直为0

  • LRU淘汰的键个数(evicted_keys): 因used_memory达到maxmemory限制,并设置有淘汰策略的实例;(对排查问题重要,可不设置告警)

  • 过期淘汰的键个数(expired_keys): 删除生存时间为0的键个数;包含主动删除和定期删除的个数。

Redis qps
  • redis处理的命令数(total_commands_processed): 监控采集周期内的平均qps,
    redis单实例处理达数万,如果请求数过多,redis过载导致请求堆积。

  • redis当前的qps(instantaneous_ops_per_sec): redis内部较实时的每秒执行的命令数;可和total_commands_processed监控互补。

Redis cmdstat_xxx

这小节讲解,redis记录执行过的所有命令; 通过info all的Commandstats节采集数据.

  • 每类命令执行的次数(cmdstat_xxx): 这个值用于分析redis抖动变化比较有用

以下表示:每个命令执行次数,总共消耗的CPU时长(单个微秒),平均每次消耗的CPU时长(单位微秒)


1

2

3

4

# Commandstats

cmdstat_set:calls=6,usec=37,usec_per_call=6.17

cmdstat_lpush:calls=4,usec=32,usec_per_call=8.00

cmdstat_lpop:calls=4,usec=33,usec_per_call=8.25



Redis Keysapce hit ratio

redis键空间请求命中率监控,通过此监控来度量redis缓存的质量,如果未命中率或次数较高,可能因热点数据已大于redis的内存限制,导致请求落到后端存储组件,可能需要扩容redis缓存集群的内存容量。当然也有可能是业务特性导致。

  • 请求键被命中次数(keyspace_hits): redis请求键被命中的次数

  • 请求键未被命中次数(keyspace_misses): redis请求键未被命中的次数;当命中率较高如95%,如果请求量大,未命中次数也会很多。可参考Baron大神写的Why you should ignore MySQL’s key cache hit ratio

  • 请求键的命中率(keyspace_hit_ratio):使用keyspace_hits/(keyspace_hits+keyspace_misses)计算所得,是度量Redis缓存服务质量的标准

Redis fork

redis在执行BGSAVE,BGREWRITEAOF命令时,redis进程有fork操作。而fork会对redis进程有个短暂的卡顿,这个卡顿redis不能响应任务请求。所以监控fork阻塞时长,是相当重要。
如果你的系统不能接受redis有500ms的阻塞,那么就要监控fork阻塞时长的变化,做好容量规划。

  • 最近一次fork阻塞的微秒数(latest_fork_usec): 最近一次Fork操作阻塞redis进程的耗时数,单位微秒。

redis network traffic

redis一般单机多实例部署,当服务器网络流量增长很大,需快速定位是网络流量被哪个redis实例所消耗了; 另外redis如果写流量过大,可能导致slave线程“客户端输出缓冲区”堆积,达到限制后被Maser强制断开连接,出现复制中断故障。所以我们需监控每个redis实例网络进出口流量,设置合适的告警值。

说明:网络监控指标 ,需较高的版本才有,应该是2.8.2x以后

  • redis网络入口流量字节数(total_net_input_bytes)

  • redis网络出口流量字节数(total_net_output_bytes)

  • redis网络入口kps(instantaneous_input_kbps)

  • redis网络出口kps(instantaneous_output_kbps)

前两者是累计值,根据监控平台1个采集周期(如1分钟)内平均每秒的流量字节数。

Redis慢查询监控

redis慢查询是排查性能问题关键监控指标。因redis是单线程模型(single-threaded server),即一次只能执行一个命令,如果命令耗时较长,其他命令就会被阻塞,进入队列排队等待;这样对程序性能会较大。
redis慢查询保存在内存中,最多保存slowlog-max-len(默认128)个慢查询命令,当慢查询命令日志达到128个时,新慢查询被加入前,会删除最旧的慢查询命令。因慢查询不能持久化保存,且不能实时监控每秒产生的慢查询个数。
我们建议的慢查询监控方法:

  1. 设置合理慢查询日志阀值,slowlog-log-slower-than, 建议1ms(如果平均1ms, redis qps也就只有1000)

  2. 设置全理慢查询日志队列长度,slowlog-max-len建议大于1024个,因监控采集周期1分钟,建议,避免慢查询日志被删除;另外慢查询的参数过多时,会被省略,对内存消耗很小

  3. 每次采集使用slowlog len获取慢查询日志个数

  4. 每次彩集使用slowlog get 1024 获取所慢查询,并转存储到其他地方,如MongoDB或MySQL等,方便排查问题;并分析当前慢查询日志最长耗时微秒数。

  5. 然后使用slowlog reset把慢查询日志清空,下个采集周期的日志长度就是最新产生的。

redis慢查询的监控项:

  • redis慢查询日志个数(slowlog_len):每个采集周期出现慢查询个数,如1分钟出现10次大于1ms的慢查询

  • redis慢查询日志最长耗时值(slowlog_max_time):获取慢查询耗时最长值,因有的达10秒以下的慢查询,可能导致复制中断,甚至出来主从切换等故障。

Redis持久化监控

redis存储场景的集群,就得redis持久化保障数据落地,减少故障时数据丢失。这里分析redis rdb数据持久化的几个监控指标。

  • 最近一次rdb持久化是否成功(rdb_last_bgsave_status):如果持久化未成功,建议告警,说明备份或主从复制同步不正常。或redis设置有”stop-writes-on-bgsave-error”为yes,当save失败后,会导致redis不能写入操作

  • 最近一次成功生成rdb文件耗时秒数(rdb_last_bgsave_time_sec):rdb生成耗时反应同步时数据是否增长; 如果远程备份使用redis-cli –rdb方式远程备份rdb文件,时间长短可能影响备份线程客户端输出缓冲内存使用大小。

  • 离最近一次成功生成rdb文件,写入命令的个数(rdb_changes_since_last_save):即有多少个写入命令没有持久化,最坏情况下会丢失的写入命令数。建议设置监控告警

  • 离最近一次成功rdb持久化的秒数(rdb_last_save_time): 最坏情况丢失多少秒的数据写入。使用当前时间戳 - 采集的rdb_last_save_time(最近一次rdb成功持久化的时间戳),计算出多少秒未成功生成rdb文件

Redis复制监控

不论使用何种redis集群方案,redis复制都会被使用。

复制相关的监控告警项:

  • redis角色(redis_role):实例的角色,是master or slave

  • 复制连接状态(master_link_status): slave端可查看它与master之间同步状态;当复制断开后表示down,影响当前集群的可用性。需设置监控告警。

  • 复制连接断开时间长度(master_link_down_since_seconds):主从服务器同步断开的秒数,建议设置时长告警。

  • 主库多少秒未发送数据到从库(master_last_io_seconds):如果主库超过repl-timeout秒未向从库发送命令和数据,会导致复制断开重连。详细分析见文章:Redis复制中断和无限同步问题。 在slave端可监控,建议设置大于10秒告警

  • 从库多少秒未向主库发送REPLCONF命令(slave_lag): 正常情况从库每秒都向主库,发送REPLCONF ACK命令;如果从库因某种原因,未向主库上报命令,主从复制有中断的风险。通过在master端监控每个slave的lag值。

  • 从库是否设置只读(slave_read_only):从库默认只读禁止写入操作,监控从库只读状态;
    如果关闭从库只读,有写入数据风险。关于主从数据不一致,见文章分析: Redis复制主从数据不-致

  • 主库挂载的从库个数(connected_slaves):主库至少保证一个从库,不建议设置超过2个从库。

  • 复制积压缓冲区是否开启(repl_backlog_active):主库默认开启复制积压缓冲区,用于应对短时间复制中断时,使用部分同步方式。

  • 复制积压缓冲大小(repl_backlog_size):主库复制积压缓冲大小默认1MB,因为是redis server共享一个缓冲区,建议设置100MB.

    说明: 关于根据实际情况,设置合适大小的复制缓冲区。可以通过master_repl_offset指标计算每秒写入字节数,同时乘以希望多少秒内闪断使用“部分同步”方式。

Redis集群监控

这里所写redis官方集群方案的监控指标
数据基本通过cluster info和info命令采集。

  • 实例是否启用集群模式(cluster_enabled): 通过info的cluster_enabled监控是否启用集群模式。

  • 集群健康状态(clusster_state):如果当前redis发现有failed的slots,默认为把自己cluster_state从ok个性为fail, 写入命令会失败。如果设置cluster-require-full-coverage为NO,则无此限制。

  • 集群数据槽slots分配情况(cluster_slots_assigned):集群正常运行时,默认16384个slots

  • 检测下线的数据槽slots个数(cluster_slots_fail):集群正常运行时,应该为0. 如果大于0说明集群有slot存在故障。

  • 集群的分片数(cluster_size):集群中设置的分片个数

  • 集群的节点数(cluster_known_nodes):集群中redis节点的个数

Redis响应时间监控

响应时间是衡量一个服务组件性能和质量的重要指标。使用redis的服务通常对响应时间都十分敏感,比如要求99%的响应时间达10ms以内。
因redis的慢查询日志只计算命令的cpu占用时间,不会考虑排队或其他耗时。

  • 最长响应时间(respond_time_max):最长响应时间的毫秒数

  • 99%的响应时间长度(respond_time_99_max):

  • 99%的平均响应时间长度(respond_time_99_avg):

  • 95%的响应时间长度(respond_time_95_max):

  • 95%的平均响应时间长度(respond_time_95_avg):

响应时间监控的方式建议,最简单方法,使用Percona tcprstat

原文地址:https://zhuoroger.github.io/2016/08/20/redis-monitor-and-alarm/


.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/327337.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

curl和wget的区别和使用

https://www.cnblogs.com/wyaokai/p/11947379.html https://blog.csdn.net/IT_hejinrong/article/details/79361095 curl和wget的区别和使用 curl和wget基础功能有诸多重叠,如下载等。 非要说区别的话,curl由于可自定义各种请求参数所以在模拟web请求…

vmware启动多个虚拟机

启动顺序 这样4个虚拟机就启动了 也够使用了 (如果出现某个虚拟机不能启动貌似多重复全套流程就可以了) CentOS 64 位5swarm20201006_3_配合第三章register CentOS 64 位6 CentOS 64 位5swarm20201007_5_第三章学完的镜像 CentOS 64 位5swarm20200927 0)关闭…

怎样在Redis通过StackExchange.Redis 存储集合类型List

StackExchange 是由StackOverFlow出品, 是对Redis的.NET封装,被越来越多的.NET开发者使用在项目中。绝大部分原先使用ServiceStack的开发者逐渐都转了过来,由于SS在其新版中不再开源,并对免费版本有所限制。 实际问题 那么用.NET的…

Java爬虫小测---ElasticSearch

项目搭建 1、启动ES,和head-master,用head-master建立索引 不建立也没事,添加数据的时候会自动创建 2、导入SpringBoot需要的依赖 注意:elasticsearch的版本要和自己本地的版本一致!所以还要在pom里面添加自定义版本…

Gradle的安装与配置

https://www.cnblogs.com/NyanKoSenSei/p/11458953.html Gradle的安装与配置 1. Gradle简介 Gradle是源于Apache Ant和Apache Maven概念的项目自动化构建开源工具,它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置,抛弃了基于XML的各种繁琐配置面…

使用 Roslyn 编译器服务

.NET Core和 .NET 4.6中 的C# 6/7 中的编译器Roslyn 一个重要的特性就是"Compiler as a Service",简单的讲,就是就是将编译器开放为一种可在代码中调用的服务, 通常在工作流引擎 或是规则引擎中都需要一项功能是计算表达式&#xf…

Rest风格---ElasticSearch

Rest风格 5.1 简介 RESTful是一种架构的规范与约束、原则,符合这种规范的架构就是RESTful架构。 操作 methodurl地址描述PUTlocalhost:9100/索引名称/类型名称/文档id创建文档(指定id)POSTlocalhost:9100/索引名称/类型名称创建文档&…

IntelliJ IDEA如何导入Gradle项目

https://blog.csdn.net/wangdong5678999/article/details/70255451 IntelliJ IDEA如何导入Gradle项目 栋先生 2017-04-20 10:14:03 95942 收藏 分类专栏: 其他 文章标签: idea intellij idea gradle 版权 最近学习Gradle,本文来重点介绍…

加密货币的本质

转载自 加密货币的本质 去年,比特币暴涨,其他币也像雨后春笋一样冒出来,已经有1000多种了。很多人都在问,加密货币(cryptocurrency)的时代,真的来临了吗?将来会不会人类不再使用美元…

.net core 源码解析-web app是如何启动并接收处理请求

最近.net core 1.1也发布了,蹒跚学步的小孩又长高了一些,园子里大家也都非常积极的在学习,闲来无事,扒拔源码,涨涨见识。 先来见识一下web站点是如何启动的,如何接受请求,.net core web app最简单的例子,大…

关于文档的基本操作---ElasticSearch

关于文档的基本操作(重点) 基本操作 添加数据 PUT /psz/user/1 {"name": "psz","age": 22,"desc": "偶像派程序员","tags": ["暖","帅"] }获取数据 GEt psz/user/…

IdentityServer4 使用OpenID Connect添加用户身份验证

使用IdentityServer4 实现OpenID Connect服务端,添加用户身份验证。客户端调用,实现授权。 IdentityServer4 目前已更新至1.0 版,在之前的文章中有所介绍。IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架学习保护API 。 本文环…

深度优先搜索和广度优先搜索

转载自 深度优先搜索和广度优先搜索 图的应用很广泛,也有很多非常有用的算法,当然也有很多待解决的问题,根据性质,图可以分为无向图和有向图。 图 之所以要研究图,是因为图在生活中应用比较广泛: 图是若…

消息队列 Kafka 的基本知识及 .NET Core 客户端

前言 最新项目中要用到消息队列来做消息的传输,之所以选着 Kafka 是因为要配合其他 java 项目中,所以就对 Kafka 了解了一下,也算是做个笔记吧。 本篇不谈论 Kafka 和其他的一些消息队列的区别,包括性能及其使用方式。 简介 Kafka…

深入解读Service Mesh背后的技术细节

转载自 深入解读Service Mesh背后的技术细节 在Kubernetes称为容器编排的标准之后,Service Mesh开始火了起来,但是很多文章讲概念的多,讲技术细节的少,所以专门写一篇文章,来解析Service Mesh背后的技术细节。 一、…

CentOS7查看和关闭防火墙

https://blog.csdn.net/ytangdigl/article/details/79796961 CentOS7查看和关闭防火墙 蔚蓝色天空sky 2018-04-02 23:22:21 708762 收藏 236 分类专栏: linux 文章标签: centos 防火墙 CentOS 7.0默认使用的是firewall作为防火墙 查看防火墙状态 f…

Visual Studio Code 1.8版本添加了Hot Exit、Zen Mode及更多调试选项

最新发布的Visual Studio Code 1.8版本有许多改进和新功能,包括防止丢失任何编辑信息的Hot Exit,方便开发人员把注意力集中在代码上的Zen Mode,新的调试功能以及更方便的设置等。 Hot Exit是一项新功能,目的是在应用程序崩溃或退出…

ElasticSearch(笔记)

简介 本教程基于ElasticSearch7.6.1, 注意ES7的语法与ES6的API调用差别很大, 教程发布时最新版本为ES7.6.2(20200401更新);ES是用于全文搜索的工具: SQL: 使用like %关键词%来进行模糊搜索在大数据情况下是非常慢的, 即便设置索引提升也有限;ElasticSearch: 搜索引擎(baidu, …

漫画:什么是冒泡排序

转载自 漫画:什么是冒泡排序 什么是冒泡排序? 冒泡排序的英文Bubble Sort,是一种最基础的交换排序。 大家一定都喝过汽水,汽水中常常有许多小小的气泡,哗啦哗啦飘到上面来。这是因为组成小气泡的二氧化碳比水要轻…

CentOS - 修改主机名教程(将 localhost.localdomain 改成其它名字)

https://www.cnblogs.com/gudi/p/7846978.html 需要关闭防火墙!!!!!!! Linux修改主机名称 碰到这个问题的时候,是在安装Zookeeper集群的时候,碰到如下问题 java.net.U…