本来这个是不想写的，理应当是一个运维的问题，结果发现近期又出现了这样的问题，有的机器配置了 ` net.ipv4.tcp_tw_recycle=1 ` ， 表示开启TCP连接中TIME-WAIT sockets的快速回收。 这种配置会导致一个问题，当服务是一个网关类的应用的时候且访问量很大的时候容易出现很多的连接拒绝的情况。 在linux 4.1内核中，`net.ipv4.tcp_tw_recycle` 参数将被移除。 具体的原因可参考以下文章： https://www.cnxct.com/coping-with-the-tcp-time_wait-state-on-busy-linux-servers-in-chinese-and-dont-enable-tcp_tw_recycle

承接上文的问题 ： [G1 垃圾回收器 GC 频繁导致的系统波动问题](https://yuxianghe.net/blog/54) 上文提到问题的解决方案有两种： 1. 设置 getMaxRequestSizeBytes 的值为 `1024*256` ，减少每一个消息的数组的大小，使其不会超过 HeapRegionSize 的一半大小，这个缺陷就是需要保证消息的大小必须在 `1024*256` 字节以内。（最后我们改成了 `1024*4` ） 2. 调整堆内存大小为8G或以上，同时增加配置 -XX:G1HeapRegionSize=4M ，使得1M的消息数组大小小于 HeapRegionSize 的一半。 采用的最为稳妥的方案二，这样当大对象过来的时候不直接分配到老年代，而是在伊甸区，回收的时间和次数明显减少，效果显著。 如下是gc的情况： ``` S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YG...

CPU波动如图所示：  内存波动如图所示：  CPU经常达到告警阈值，触发告警信息，第一反应就是去看下java进程里哪个线程耗CPU资源多，其实这里看到内存波动情况就大致能猜测出和GC有关。 ``` top -Hp PID PID %CPU %MEM TIME+ COMMAND 89011 70.9 31.8 154:44.25 java 89001 7.7 31.8 216:48.06 java 90049 7.7 31.8 57:37.76 java ``` 将 `89011` 转换为十六进制 `15bb3` 通过jstack导出来的线程快照可以找到 `15bb3` 对应的线程，结果如下所示： ``` cat 01_jstack.txt ...

抽空自己写了个简易版的rpc框架，想了下怎么搞负载均衡， 最简单的方式就是搞个配置文件放置服务地址，直接读配置文件，转而想到配置文件可以放zk，相当于用zk来做配置中心或者服务发现。 优秀的dubbo项目就可以这么做，马上参考了下谷歌的grpc,发现了一篇谷歌很棒的文章，拜读了下（也借用了谷歌这篇文章的图片），很不错，想写一些我自己的见解。 传送门： https://grpc.io/blog/loadbalancing/ rpc通信本身并不复杂，只要定好协议怎么处理问题不大，但是负载均衡的策略是值得推敲的。 一般情况下，负载均衡的策略有以下两种 ### 1. 代理服务 客户端并不知道服务端的存在，它所有的请求都打到代理服务，由代理服务去分发到服务端，并且实现公平的负载算法。 客户机可能不可信，这种情况通过用户面向用户的服务，类似于我们的nginx将请求分发到后端机器。 缺点： 客户端不知道后端的存在，且客户端不可信，延迟会更高且代理服务会影响服务本身的吞吐量 优点： 在中间层做监控等拦截操作特别棒。 如图： ![](https://cdn.yuxianghe.net/image/blo...

我们的服务使用了kafka队列，在消费kafka队列的时候是需要配置消费者线程数，单台机器的某topic使用了16个线程消费，姑且理解成单台机器16个消费者消费这个topic。 这个topic的partition有100个，目前有6台机器，总共 `16*6==96`个消费者，这就意味着有96个partition被占用着，这没什么问题，因为空闲了4个。 但是当机器横向扩展的时候，比如扩展到8台机器，那么线程数就是 `16*8=128` ,这就意味着有 28个消费者是闲着的。 起初观察到这个现象的时候是因为看到新添加的两台机器负载很低，负载远比旧的6台机器低，查看jstack日志发现消费者线程一直在kafka的某topic上poll，8号机器的16个消费者的状态是一样的poll状态。 这个现象很奇怪（使用camel消费的kafka），马上我打开kafkaManager找到这个topic，发现100个partition里面最后4个partition由7号机器在占领着消费，没有8号机器的ip在消费这个topic。 看到这里，一计算消费者数量就明白了，线程数大于partition数量的时候就会出现这种情况。 ...