bigzuo 的博客 | Bigzuo's Blog
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
项目开发过程中经常会需要生成一个唯一ID，并且由于现在项目应用都是集群部署，所以更多时候还需要保证唯一ID支持分布式。
一些情况下，开发人员为了省事，会直接使用时间戳System.currentTimeMillis()
或者是UUID。这两种方式都存在不完善的地方。尤其是采用时间戳，时间戳本质是毫秒数，完全不支持分布式，会存在很高可能导致生成的ID重复。UUID虽然本身生成机制可以保证全球唯一，横向扩展性好，但是部分场景下，UUID长度可能过长，并且UUID是字符串类型，对需要对ID进行排序、对比的场景支持的并不友好，索引效率也很低。
鉴于以上原因，我们基于Twitter 开源的分布式ID生成算法Snowflake重写了一套分布式ID生成算法，即可以保证分布式唯一，又可以解决采用时间戳或者UUID带来的问题。
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
今天在重写Twitter 的分布式ID生成算法 sonw flake算法时，遇到一个问题，即一个整数在多次相乘后，输出的结果是0！对应的测试程序如下：
1 | int a = 1; |
后来思考了一下才反应过来，这个相乘的结果，远超过了Java int类型可以表示的范围。Java int类型可以表示的范围才是-$2^{31}$到$2^{31}$-1。
但是为什么输出结果是0呢？
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
Tomcat 7，JDK1.7， Windows 7
最近一个很久没有运行的程序启动时，出现java.lang.LinkageError异常，查了一下，是因为在应用程序的lib目录下和tomcat的lib目录下有相同的slf4j-api-1.7.7.jar jar包导致的。果然，删除掉tomcat lib目录下对应的jar包后，应用程序启动正常。不过，为什么不是删除应用程序lib目录下重复的jar包呢？因为这Tomcat个jar包不是Tomcat lib目录下自带的jar包，是开发人员添加进去的。为了避免以后再出现这个问题，所以要删除Tomcat lib目录下的重复jar包，深入原因见下文。
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
Kafka 0.8.2，JDK1.7
项目组生产环境kafka集群在进行CPU、内存升级时，升级后重启kafka broker时出现日志文件加载异常的报错，导致重启失败。具体报错日志如下：
2017-02-10 00:35:52,237 ERROR log.LogManager: There was an error in one of the threads during logs loading: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
2017-02-10 00:35:52,237 INFO log.Log: Recovering unflushed segment 0 in log Bacth_time_DB_B_ALS_201702080800009457085-9.
2017-02-10 00:35:52,238 INFO log.Log: Completed load of log Bacth_time_DB_B_ALS_201702080800009457085-9 with log end offset 408
2017-02-10 00:35:52,239 FATAL server.KafkaServer: [Kafka Server 1], Fatal error during KafkaServer startup. Prepare to shutdown
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1911)
at kafka.log.Log$.parseTopicPartitionName(Log.scala:833)
at kafka.log.LogManager$$anonfun$loadLogs$2$$anonfun$3$$anonfun$apply$7$$anonfun$apply$1.apply$mcV$sp(LogManager.scala:138)
at kafka.utils.Utils$$anon$1.run(Utils.scala:54)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
Kafka 0.8.2，JDK1.7
最近我们在生产环境执行删除无用的kafka topic的操作时，因为错误的按照8.2版本之前的删除方式操作8.2.2版本的kafka，导致删除过程异常，删除后出现consumer正在消费的其他正常topic的partition的offset值偏移的情况，导致大量消息重复消费，并且产生连锁反应，给我们的系统稳定性产生明显影响。
原创文章，如需转载，请注明来自：https://bigzuo.github.io/
Kafka 0.8.2 ，JDK1.7，producer api: kafka.javaapi.producer.Producer
项目组在16年引入kafka组件作为消息中间件，之后慢慢有更多功能接入kafka，虽然中间出过几次小问题，但均不影响主要功能。直到近期一个新功能也接入kafka后，我们发现kafka集群CPU使用率变得很高，正常运行时CPU使用率都在40%-60%，并且随着新功能往kafka发送的消息量越来越大，出现发送延迟也越来越明显，后来基本大部分情况下往kafka发送一条消息需要10s以上，以至于导致该新功能完全不可用。但是这个时候我们发现kafka集群负载正常、IO正常，并且部分接入同一个kafka集群的其他功能发送消息也都正常。