最近一直在进行手机推送服务器的研发，代码采用Java实现。netty作为一个优秀基于NIO的客户、服务器端编程框架，当然是首选的。server的研发必然是充满血与泪的，除了要熟悉Java的NIO，还得对tcp的封包、拆包，协议的设计、对象的序列化；压缩方式的选择等等之外，对Linux内核的调优是一件绝对比前面任何一个都要复杂。由于采用Java开发，由于Java的内存墙等诸多因素的影响，服务器支持的长连接我规划在一个server大概50W左右。可能对于一些C、C++服务器编程的码农来说这个链接数还真算不了什么，但是对于Java来说还是相当不错了。关于Java的内存墙方面的东西此处有一篇好文章推荐给大家，链接如下：http://ifeve.com/jvm-performance-optimization-java-scalability-5。既然一台服务器要支持50W的长连接 ，如果不对Linux内核进行调优，server的支撑的链接数和半链接的回收都会存在较大的问题。

前面YY了很多了，OK那我们下面进入正题。调优，顾名思义那就是碰见问题才调优，下面就是我碰见的问题和解决方案：

1.要支持50W的长连接，TCP栈对内存的使用需要调大。tcp_rmem和tcp_wmem我们都采用缺省值8KB，那么一个tcp链接，需要占用的内存大概为16KB。
一个简单的计算如下：接近8.0GB TCP内存能容纳的连接数，约为 8000000KB/16KB = 50万。所以下面我分别配置成3G，8G，12G，一定注意单位是page，大小一般为4KB。

1

>net.ipv4.tcp_mem = 786432 2097152 3145728

最近研发推送方案，需要大量线程来模拟手机客户端。在模拟手机客户端的时候，单个JVM线程数量始终卡在一万多一点，然后就报如下的错误java.lang.OutOfMemoryError: unable to create new native thread。我在网上找了很多资料，都是分析32位的，都是准备模拟几千个或者几万个水平。因为我是使用64位的linux,并且要模拟50万，发现很多都不是很详细，所以写了这篇文章。

对于这个OOM，根本无需多言，网上一堆关于JVM线程数的计算公式，此处我不妨再次引用一次:(MaxProcessMemory - JVMMemory – ReservedOsMemory) / (ThreadStackSize) = Number of threads。MaxProcessMemory：进程最大的寻址空间，关于不同系统的进程默认的最大寻址空间，可以参考下图。

hadoop在线运行已经很长一段时间了，下面就是我在上下线datanode和tasktracker步骤。因为datanode节点不一定是tasktracker，即使datanode和tasktracker在同一节点，你也可能只上下线其中一个，所以我在配置dfs和mr的include和exclude的时候，分开配置。

namenode中hdfs-site.xml配置

1
2
3
4
5
6
7
8

<property>
 <name>dfs.hosts</name>
 <value>/ddmap/hadoop-1.0.4/conf/hdfs_include</value>
</property>
<property>
 <name>dfs.hosts.exclude</name>
 <value>/ddmap/hadoop-1.0.4/conf/hdfs_exclude</value>
</property>

dfs.hosts所对应的文件中列出了所有可以连接到namenode的datanode，如果为空则所有的都可以连入。dfs.hosts.exclude所对应的文件中列出了禁止连接namenode的datanode节点。如果一个节点在这两个文件中都存在，则不允许连入。

虽然mongodb作为一个款明星级的NoSql数据库，但是它的磁盘回收却让很多人较为头痛。

说明

1. 下面的方案只适用于replica sets模式的mongodb集群。
2. 我们线上的mongodb版本为2.0.0，但是也适合于其他的版本。

自动同步方案

依赖于mongodb的同步方案，即不采用fastsync方式。这种方案比较简单，但是只能针对数据量和新增数据量不多的情况。因为如果你的数据量太大而新增数据又太多，可能就会出现同步时间太长，而oplog已经把你还没有同步的日志给覆盖了，从而导致集群数据不一致的情况。具体操作步骤如下：

1
2
3
4
5
6
7
8
9
10

1.首先在primary将需要整理的secondary下线：rs.remove(“172.16.1.153:10000”)。
2.将下线的secondary关闭，并且删除所有数据文件。
3.将配置文件中fastsync=true修改为false，重启该节点。
4.在primary将该节点加入集群，等待数据同步：rs.add({_id:需根据情况设定,host:“172.16.1.153:10000”})。
5.一定要将fastsync修改成true，防止以后重启又全量同步，除非你真的就是这样设计的。
6.等secondary同步完成之后，会自动上线，只需要通过命令观察该节点状态。
7.该节点上线之后，进行数据对比，如果数据没有问题，就对别的secondary节点进行操作。
8.等各个secondary节点全搞定之后，将primary降级，让secondary节点升级为primary 。
9.primary降级成secondary之后，重复1-6步骤。
10.如果你原来的primary上线之后，你还是想让它成为primary，那么就进行升级操作，升级操作跟降级操作一样，只是设置的值不一样而已。

MongoDB在我们的生产环境中已经大规模的使用，它的性能与稳定已经得到的充分的验证，稳定在线的时间已经有一年多了。在这个过程中的确给我们带来了很多性能上的优势，虽然它不像关系型数据那样有方便的join查询，但就目前我们的应用场景这些缺点（暂且把它当做缺点吧）都是可以接受的。最近在思考了下nosql数据库并发控制方面的问题，在此记录一下。

数据库的并发控制机制不外乎就两种情况：

1. 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。
2. 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性，乐观锁不能解决脏读和多读的问题。
   悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好。
   乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。

随着公司的发展，团队成员和项目数越来越多，系统架构不可避免的要向系统安全和开发运维的成本等方面倾斜。毕竟过了小米加步枪的高速发展阶段，我们必须要鸟枪换炮，将系统的质量提高一个层级。

需求

绝大多数项目都离不开包含私密信息的配置文件，这些配置信息之前是分散在数以百计的项目中。不但管理起来麻烦，而且配置信息都放在项目中不可避免的存在安全隐患。我们经过分析研究，发现很多项目的配置都存在共性，如数据库的配置，日志的输出，ZK服务器的地址等等。虽然在maven中有阿里的auto-config插件，在安全性方面有所提升。但是由于该插件只能工作在maven，不能用于gradle等构建工具，并且每个项目还要按照要求编写模板。所以我们需要代码和配置完全分离，不依赖于任何的构建工具，项目代码中只有代码逻辑。

由于我们有些项目中的配置还需要实时的变动，并同步到所有机器，写死在配置文件中，那么服务就必须要重新启动，当然通过JMX或者通过服务调用来修改都行，但是如果服务集群较多，就会存在不小的工作量。所以我们需要希望我们的配置有发布订阅的功能。

最后所有的配置信息集中存储，统一管理，各个项目中不再需要配置文件。开发人员只需要关心业务，配置全交给运维人员，并且如果配置如果出现异常，可以快速回滚。

Thread中大量的方法已经被抛弃，很多人可能都知道它们线程不安全，本篇文章就是要详细的介绍这些不被推荐的方法背后隐藏的诸多陷阱。

Thread.stop

当一个正在运行的线程，被执行stop时，该线程会抛出一个ThreadDeath实例。如果此时该线程已经进入管程)中，就可能使受管程保护的对象出现不确定的状态，从而导致使用该对象的别的线程出现问题。这样的对象，我们称之为损坏的对象。当线程操作包含损坏对象，任意的行为都会影响结果，而这些行为又是琢磨不定的。ThreadDeath不像别的未检查异常，它会悄悄的杀死线程，不会有任何警告，从而导致程序腐化。代码腐化可能会在任何时候导致实际损害发生，甚至在未来几小时或者几天。