双十一期间查询服务某节点 OOM 原因分析
> 背景： 因为双十一期间，物流在双十一之后的压力是巨大的，在之前我们的某ES集群已经扩了三个数据节点，今天11.12号发现集群的机械硬盘的机器根本扛不住，
决定临时就两个压力大的节点进行迁移到ssd机器，迁移是没有问题的，但是迁移完成后检查应用日志发现了一个惊天的秘密。
问题： 查询服务其中一个节点在凌晨1点30分宕机，直到1点35分恢复，挂了足足有5分钟.
查询服务是查询数据库和es的，收拢了大量的查询操作在里面，还有少量的定时任务。
这个服务一直以来都是很稳定的，如果不是查日志根本就没有发现这个问题（运维的监控没有做好）。
随意的看了下当时java进程的jstat信息：
```
2019-11-13 01:32:31 实例名称: query_web_01 实例PID号: 126944 jstat详细信息
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FG...
2019-11-13 07:29
大型 kafka 集群平滑迁移
我们有一套kafka集群属于比较大的业务量在用的，里面的消息很重要且量大，因为历史原因，部署在虚拟机上，现在想在双十一高峰来临前完全迁移到物理机。
迁移之前还是很担心数据是否丢失或者对应用有影响，能否做到平滑迁移，所以挑选了业务量少的凌晨2点半开始操作。
### 以下是实现方案：
1. 配套的zk迁移就比较简单了，起新节点加入zk集群，稳定后关停旧节点。
2. 新增N个broker加入集群，将所有topic分区只分配给新broker，执行分配任务后，kafka将旧broker的分区数据复制到新broker，新broker成为各分区的leader，随后kafka删除旧broker上的分区数据；
3. 整个过程中客户端应用正常生产消费消息，执行结束后使用新的消费者组从头消费可以获取到全部历史消息。
4. 停止旧broker后，正在运行的客户端应用正常生产消费消息，新建客户端连接旧broker失败，连接新broker则正常。
### 真实的执行过程：
zk的迁移过程很快，但是会有少量的提交元数据失败（因为业务量少）。
凌晨2点多，这个时候的kafka的消费者的数据消费是稳定的，没有积压，修...
2019-11-12 16:27
shardingsphered 的线程安全问题
shardingsphere版本 3.1.0 ，也是目前的最新的正式版，项目并发量很高很笨重（启动较慢），且使用了按天分表策略，在使用shardingsphere的过程中发现其存在分表策略的线程安全问题，会导致分表策略没有执行，直接查询的没有分表策略的逻辑表。
原因：
`io.shardingsphere.core.parsing.antlr.extractor.impl.FromWhereExtractor`
这个实现类有一个如下定义：
```
public final class FromWhereExtractor implements OptionalSQLSegmentExtractor {
private final TableNameExtractor tableNameExtractor = new TableNameExtractor();
private PredicateExtractor predicateSegmentExtractor;
...
public Optional<FromWhereSegment> extract(fin...
2019-11-12 10:06
记一次字符类型转换发生的生产事故
我们有很多套kafka集群，其中大致可以划分为一级队列kafka集群和二级队列kafka集群，消息发送到一级队列kafka集群，消费一级队列进行逻辑处理后入库再加入一些包装的字段统一扔到二级队列供其他消费者进行消费，我们在消费一级队列的过程中包装过程有如下伪代码：
```
messageInfo.setPropertyCompanyId(String.valueOf(company.getPropertyCompanyId()))
kafka.produce(messageInfo);
```
上面是一级队列消费者消费消息进行处理，然后扔到了二级队列。
接下来是二级队列消费者进行消费的代码：
```
messageInfo = kafka.getMessageInfo();
msg.setPropertyCompanyId(Integer.parseInt(messageInfo.getgetPropertyCompanyId()));
```
很简单的可以看出来，一级队列的消费者定义的 `propertyCompanyId` 字段是String类型，但是在二级队列这个字段是int类型，在不为...
2019-11-06 12:43
ElasticSearch7 的特性
看了下公司内部用的ElasticSearch集群是 2.3.4 的版本，想升级到新版本，众所周知es这尿性更新速度很快，且有些大版本不向前兼容。
这主要是因为lucene，在大四的时候接触lucene，对它要升级的过程深有感触，除了重建索引，没有别的方法。
所以这次要升级想采用用类似于oracle数据库迁移到mysql的稳妥方法，双写，重建索引是下下策，因为数据量太大，且要保持数据增删查改平稳。
目前我们的问题：
2.3.4 版本及其之前，在并发量高且数据量大的时候，存在数据删除时主分片和副本数据不一致的情况。
所以这几天看了下 ElasticSearch 已经刷版本号到了7了，网上的中文区目前好像也没有对这个版本的一些新特性的详细介绍，所以想着总结一下。（内容来自ElasticSearch官网的更新介绍和官方英文文档）。
感兴趣的朋友也可以参考官方的文档：
https://www.elastic.co/guide/en/elasticsearch/reference/7.4/release-highlights-7.0.0.html
https://www.elastic.co/...
2019-10-27 07:47