小程故事多的博客

首先要特别感谢赵崇贺同学利用业余时间进行的压测，才能为本文提供专业的测试数据一、测试环境准备 Cpu 内存 硬盘 Intel(R) Xeon(R) CPU E5520 @ 2.27GHz 32G 6TKafka集群，服务器个数：3台 采用CMS垃圾回收 JVM运行参数-Xmx1G -Xms1G -server -XX:+UseParNewGC -XX:+UseC

一日凌晨，手机疯狂报警，短信以摧枯拉朽之势瞬间以百条的速度到达，我在睡梦中被惊醒，看到短信的部分内容如下：Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.star

本文是“论代码级性能优化变迁之路一”（http://www.jianshu.com/p/c4a748002e66） 的第二篇。在上一篇我们主要介绍了所遇到问题的五点，那么今天接下来讨论剩下的问题，我们先再回顾一下之前讨论的问题：1、单台40TPS，加到4台服务器能到60TPS，扩展性几乎没有。 2、在实际生产环境中，经常出现数据库死锁导致整个服务中断不可用。 3、数据库事务乱用，导致事务占用时间

一、前言大家好，很久没有和大家一起讨论技术了，那么今天我将和大家一起探讨我负责的某项目的性能变迁之路。我们以前看到的很多架构变迁或者演进方面的文章大多都是针对架构方面的介绍，很少有针对代码级别的性能优化介绍，这就好比盖楼一样，楼房的基础架子搭的很好，但是盖房的工人不够专业，有很多需要注意的地方忽略了，那么在往里面填砖加瓦的时候出了问题，后果就是房子经常漏雨，墙上有裂缝等各种问题出现，虽然不至于楼房

1、前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。恢复后，Twemproxy 能够自动识别、恢复并重新加入到 Redis 组中重新使用。 2、Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。如果要新增加一

因为最近工作的关系，要把异步任务从应用服务器中拆分到专门的异步处理服务器中.方案一是采用MQ的方式将任务消息发出，在服务端进行处理，如下图所示： 这种方案是采用MQ作为中间的媒介，在服务端采用线程池异步处理任务，处理完成之后将结果发送到MQ中，客户端采用侦听的方式得到结果继续进行处理。 这种方案的不足是，可能在某些需求的情况下，需要将结果存放到共享的HashMap或者Threadlocal