在处理生产环境问题的过程中发现12号那天某kafka集群有少量的数据丢失，概率大致在千万分之三。 数据写入kafka之后，就完全消失了，消费者完全没有消费到这个数据。 通过找到那天的数据，查看有问题的数据在写入kafka的时候上下文应用日志发现有少量以下报错: ``` [2019-10-12 11:03:43,xxx] This is not the correct coordinator. ``` 理论上正常情况下kafka是不太可能丢数据的，如果出现这种情况，必然是开发人员或者硬件引发了什么问题，因为写入日志是有的，看了下应用配置 ``` acks=1 ``` 马上意识到，问题突破口应该在这里。 ``` acks=0 生产者能够通过网络吧消息发送出去，那么就认为消息已成功写入Kafka,一定会丢失一些数据 acks=1 master在疏导消息并把它写到分区数据问津是会返回确认或者错误响应，还是可能会丢数据 acks=all master在返回确认或错误响应之前，会等待所有同步副本都收到消息 ``` 可能以前是为了保证性能够快，选择了折中的应用配置 `acks=1` 。 马上想到去看下k...

目前为止在这边总共升级过三次基础组件，第一次是kafka的客户端，全面涉及到的20+个项目全部升级，第二次是升级spring组件，也是所有项目升级，第三次是json组件升级。 在升级基础组建的过程中发现了一些很麻烦很严重的问题，项目的包依赖问题，因为每次基础组件升级需要涉及到20+个项目，可以说几乎都是‘微服务’，说‘微’其实也不‘微’，一个项目一百多M，启动要一分钟以上，本地启动需要2分钟以上，当然本地一次能不能启动就两说了。。。 我在这之前是没有在工作中用过spring的，所以对spring是很陌生，说来也很惭愧，SSM或者SSH三大框架都没在工作中用过，最早是公司自研的一套web框架，后来在小牛这边是在大数据部门接触多是多线程高并发问题和破解方面的技术问题，不过我在学生时代就听闻spring的大名已经很久了，一直没有机会接触。 现在这边用的spring还是比较老的版本，升级的时候真是痛苦，第一是我们用的spring的版本简直是乱，包依赖关系连我自己都屡不清。当然这种现象不仅仅是spring组件，其他组件也一样是这个情况，只是这个比较典型。 很多公司企业喜欢给应用戴上‘微服务’的帽子，就...

redis集群因为业务增长导致内存容量不足，理论上单节点内存16g左右的话，扩节点的是很合适的，但是现在单节点内存不高且想无感知的扩容。 如果扩节点的话是需要起节点加节点然后迁移槽和数据，还有一种很骚的操作没这么复杂，直接先升级从节点的内存，然后主从切换，切换好了之后直接升级原主节点的内存，这样无缝无感知的完成了节点内存扩容。 理论上这种方式在PPT上是写的很完美的，先升级从节点的内存，然后主从切换，再升级,但是实际操作上却发现再好的PPT方案也拦不住老代码神奇代码的摧残。 但是在进行主从切换的时候遇到了一个问题，所有的连接到这套redis集群的应用日志报错刷屏了。 ``` redis.clients.jedis.exceptions.JedisDataException: EXECABORT Transaction discarded because of previous errors. at redis.clients.jedis.Protocol.processError(Protocol.java:127) at redis.clients.je...

2019-09-03 17:06:25 机房网络出现一分钟波动，交换机问题导致kafka集群相互之间偶尔失联。 kafka日志如下所示： ``` [2019-09-03 17:06:25,610] WARN Attempting to send response via channel for which there is no open connection, connection id xxxxx (kafka.network.Processor) [2019-09-03 17:06:31,906] INFO Unable to read additional data from server sessionid 0x46b0xxxx027, likely server has closed socket, closing socket connection and attempting reconnect (org.apache.zookeeper.ClientCnxn) [2019-09-03 17:06:32,076] INFO zookeeper state changed (Disc...

说来也奇怪，协助武汉研发部门的发版本，本来是一次很简单的版本发布，折腾到了晚上12点。 原因如下： > 发版之前进行修改 `disconf` 配置中心的配置数据，结果发现 `disconf` 的XX项目配置中心管理界面的配置文件页面为空。当时就吓坏了，以为是服务挂了，如果配置中心整个服务挂了就很严重了，马上看了下别的项目的配置中心页面是正常的， 唯独XX项目的是空白，赶紧看了下XX项目的应用日志，一切正常，由此马上F12查看 `disconf`后台的请求，发现返回了一段json错误信息，服务器内部错误。 进入生产环境查看 `disconf` 的报错日志，发现报错表现很模糊： ``` xx:xx:50.591 [http-bio-xxxxx-xxxx-exec-xx] WARN c.b.d.c.handler.MyExceptionHandler - /xxx/xx/xxx/list ExceptionHandler FOUND. com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a...