讲实话，刚开始两周还是蛮清闲的，这两周还是蛮忙的，就在这里总结一下这一个月都学到了啥吧。
主要的分为以下几点，日志系统，压测，区块链的理解以及相关的问题解决思路。
- 日志系统
项目原来等于是用的logging插件的logback去写日志，后来改成了log4j2。其实用啥都不重要，主要是里面日志的细节。
比如说，日志分为几个级别，但是咱们一般打印的都是分成两种，info和error，至于debug级别的日志，一般都是在我们出现了一些疑难问题，需要改变日志级别，毕竟在线上测试的时候，使用日志去debug是最方便的，很容易就能看出问题，有些人可能会说，我直接打印出来不也行吗，但是我想说，很多情况下，你用postman去调试接口，不容易出错，很多错误只有在压测场景再能暴露出来（下面我会都说到），然后几百万行的日志，你去找printf？
另外还有就是Rolling切割文件的事情，这个得看个人体验了，一方面，我们不能让日志太大，硬盘爆炸，一方面，线上出错，我们还得及时订正。
至于切割成多大，多长时间删一下存储的日志，这个就得看自己了，也得看服务器的硬盘大小来决定。
在日志方面还有一点想说的就是，我们既然是通过日志去找bug，那么就得需要一个正确的打日志的地方，一般我们都会首选，入参的时候，用日志说明一下，我入的是什么参数，可以用fastJson库的Json.toJson去转义一下，但是这里又有一个坑就是，我们不能无脑转json，比如，如果是一个object对象，你像转成一个User，那肯定是不行了，可以考虑采用序列化反序列化来决定，网上都有指南的。
然后，参数经过处理之后，我们可以返回一下参数，还比如，我们借助了某一种数据库入参，也可以使用一下日志，打印一下，我们入sql的内容参数是什么。
- 压测
最近一直在用的压测工具是Jmeter，至于使用方法就不说了，设置那个线程数，不代表客户端的并发，也不代表服务端的并发，Ramp-up，也不是代表0秒就是并发，都是误区。一般情况下，我们压测的时候，都会把他设置成为，出现错误立即停止。
另外，如果我们测试的线程数超过800-1200的话，Jmeter概率会出现堆栈溢出，可以找到.bat文件去修改xms xmx，这个百度有，就不说了。
Jmeter在压测工具里算比较好用的，我们在测试中，一般都是在linux环境，填内网ip，部署在linux服务器进行测试，不然公网到私网的访问，延迟太高了。
- 区块链的理解
这个其实是困扰我两周的主要问题，压测的时候出现各种各样的问题，像OOM，共识错误，私钥未注册，redis溢出，更换nosql等等的。。。
其中学到最多的就是oom相关的了，说一个排查思路，一般宕机了，我们看jmap -heap <pid>就能知道新生代老年代的比例了，要是oom，一眼就能看出来。
至于排查方法，我们追本溯源，为什么会oom，还不是因为你有对象占用太多内存没有被gc了，可以打包成很多个dump文件，用jprofile去进行分析，就能知道是哪个对象占用过多内存了，然后你再去分析就行了。
另一方面，我想说的是，你oom了，也可以适当的提高一下xms 和 xmx，而且java是基于线程的，你一台机器起多个进程是没有用的，jvm会叠加的，除非是特殊需要。
还是挺想说的，共识还真是一个挺神奇的东西。
但是有一点搞不懂的是，为什么redis作为存储容器的qps远远低于嵌入式数据库rocksdb的qps
