这一年来（2019 总结）
> 本来是早就想写2019年的总结，前段时间忘记了，这几天肺炎疫情严重，在家办公，正好抽空写个给自己的总结，也没有做什么格式编辑，想到哪里写到哪里，就当作随笔写的年终总结吧。
2019年对于自己来说是变革的一年，年初做需求，年中的时候领导离职，赶鸭子上架接任了这个烫手山芋，起初我自己是不看好自己能做好这个小领导，几番推辞还是无奈受命，这不是矫情，其实当初自己也有点走的想法，年龄和阅历都不足以承担这个重任，特别是这还是整个公司的核心业务，但是自己的性格好像就是那种越刺激的事情越想搞定的人，随着慢慢熟悉，好像做的也还可以，哈。
从实习进入o公司到x公司，再到f公司。一切好像都是这么巧合，在o，老大说接任负责人，那年才毕业一年多，我感觉觉得自己好像不是很行，转去了n公司，在n公司刚第一次接触大数据，半年时间转为数据收集处理的技术负责人，带了个五六人的团队，一不小心成为了公司内某技术领域的专家（滑稽），在那里的确学习到了很多，技术的长进不是最重要的，是学习的能力，解决问题的能力和方法，但是好像在n公司做到最后发现数据处理得到的结果都给人做了嫁衣，一个大公司业务很赚钱是好事，但是遇见了中层勾结组建私下公...
2020-02-10 09:39
深入探讨布隆过滤器
看了很多网上的文章好像对布隆过滤器有什么误解，不是抄袭就是拷贝来的文章，没有说到根本和真正的生产实践，还有的就是只说原理，但是你会发现合适的实现和原理有时候并不完全一样。
就以谷歌的guava实现布隆过滤器为参考吧。
原理什么的就不详细介绍了，直接进入正题。
如果要让布隆过滤器趋于完美，首先要有一个预估的数据量，和误差率，需要通过这两个值来算到你需要的合适的hash函数的个数和合适的bit位长度。
这个计算公式早已有了数学家提供了数学理论基础，谷歌也是这么实现的。（按照现有的一些网络上各种拷贝的文章，这种值是随便取，没有根据）
在维基百科中我们可以看到这样的一些公式：
求M和K， https://en.wikipedia.org/wiki/Bloom_filter
参考这个公式我们可以用代码实现这个公式函数，直接调用即可。
1. 首先要先求出M，bit位的长度，M是在已知的预期数据总数和预期的误差率的基础上得到的。
```
/**
* 求M，bit位长度。
...
2020-01-08 02:53
jvm-sandbox 内存泄漏的严重 BUG
我们的A应用第一次出现宕机是4号节点,时间在2019-11-24 晚上19点
原因是发生了fullGC，根本原因是元数据空间爆了。
```
2019-12-05T09:43:14.678+0800: 126777.294: [GC concurrent-root-region-scan-start]
2019-12-05T09:43:14.680+0800: 126777.297: [Full GC (Metadata GC Threshold) 2019-12-05T09:43:14.684+0800: 126777.300: [GC concurrent-root-region-scan-end, 0.0063095 secs]
2019-12-05T09:43:14.684+0800: 126777.300: [GC concurrent-mark-start]
2019-12-05T09:43:14.684+0800: 126777.300: [Heap Dump (before full...
2019-12-05 12:14
循环调用导致的 OOM 问题分析解决
> 问题背景：
2019-11-26 14：30左右我们的对外的web应用出现RPC调用超时的异常告警，查了日志下是调用内部广告系统超时，马上联系运维的同事去跟踪排查，因为不是自己项目组的东西，很多是没有权限干涉的。
好在对接口的调用超时有做异常检查，并不会对用户产生影响，但是线程积压的情况是会有的，问题不大。
现在问题是他组同事排查了一天没有找到原因，这就很尴尬了，我们的权限又不足以去查看别人的应用和代码，干着急，只能曲线救国。
在没有代码查看权限和机器权限的情况下要处理这种问题还是有点尴尬的，首先找到该应用的监控发现GC是有异常的。
并不是一个节点是这种情况，每个节点都有可能出现，而且是无规律的，断断续续的FullGC，每一次的时间很长。
初步判断是内存泄漏。
找运维聊了下那个应用的JVM配置，之前该应用是4G的内存分配，由于量的增加，4G已经不够，后来增长到了8G，现...
2019-11-27 08:15
2019 年双十一高峰感想
今年的2019双十一高峰基本上落下帷幕了，一般情况下是为期一周，到今天17号，我们做到了2019年双十一高峰期间核心业务0故障，稳如山，从双十一前一个礼拜到今天，半个月的时间，相比去年，今年感觉特别的漫长，可能是自己的心中的责任更大了些，在一线站久了好像也麻木不了，反而会更紧张。。。
2018年的双十一高峰我也做过总结: [双十一高峰感想](https://yuxianghe.net/blog/19)
去掉敏感的业务数据，下面就说下今年双十一的大致技术上的过程。
### 2019年双十一技术类过程回放：
11.10号之前我们做了很多优化，还因为优化领了一个严重生产事故（ [记一次字符类型转换发生的生产事故](https://yuxianghe.net/blog/63) ），迁移了几个kafka集群和扩了es集群.（ [大型kafka集群平滑迁移](https://yuxianghe.net/blog/65) ）
11.10号下午小会议总结下今年双十一高峰期的各种问题预案。
11.11号迎来了双十一，因为是物流业务，所以这一天的量和平时差不多，高峰期在后头。
11.12号，量开始显著上...
2019-11-17 05:14