明天就要离职了，下家也没有确定，心里还是有些不安的，只能希望自己有一个好的前途啦。月初已经明确跟老大说要离职了，但因为项目较赶，且存在性能问题，老大一直不给批。我只能硬着头皮上了，解决目前项目中存在的性能问题。很多时候真的是把人给逼出来的，在摸索中成长。谈谈最近项目上遇到的一个问题吧。

设备端往云平台发送日志信息，由于设备数量较大，导致上送的日志信息较大，在前期设计的过程中更新数据库都是采用直接插入的方式，在设备数量达到一定量之后，性能急剧下降，同时上送的过程占用了IO的性能，导致读写数据库都非常的慢，为了解决这个问题，我将数据库部署在另一台服务器上，而服务器端只接收数据，解析数据，计算，保存，这个过程减小了服务器端的压力，但是毕竟两台设备处理，提高性能是必然的。

目前测试基本确认，将数据库和服务器分离之后，5分钟内，数据库插入数据量超过100W条，因此基本满足目前的功能需求。

为了实现这个100万条的数据量采用了如下的一些优化点，主要采用了内存提高性能的方式:
   >> 服务器端的修订
         1.1 在接收到包的过程中加快数据的处理能力，采用队列的方式将待处理的数据分发给不同的日志处理线程，该队列需要根据部署设备的参数进行调整，同时需要进行互斥同步，防止设备端无限制的上传信息。未来考虑采用内存文件系统，减少维护内存的代价，同时不能很好的解决服务器重启的问题。

         1.2 服务器与数据库的交互过程中采用了队列，该队列根据不同信息的数量进行合理的判断和设计。插入操作的过程对于每种不同的日志类型分别进行更新数据库操作。因此在日志处理线程需要和数据库更新线程进行同步，尽量使得更新数据库的过程中采用批量更新或插入。
      整体而言，服务器端采用了内存换性能的方案。
      
      第一版开发中采用了从硬盘读日志的方式，该方案基本已经被重写了，原因是硬盘的IO存在一定的瓶颈，导致对其他各阶段的处理都提高不大。因此在数据量较大的服务器中尽量减少硬盘的使用，能使用内存的情况下尽量使用内存。也可以使用内存文件系统，但是文件系统的容量大小需要进行合理的设计。

      >> 数据库部分的修订
         1.1 选择合适的主键，在mysql中选择合适的主键，在进行数据库操作的过程中将有大幅度的提升，比如需要更新设备当前的位置信息，采用设备的表示作为主键，则可以直接使用mysql中提供的replace代替先查询在insert、update的方式，同时replace支持批量的操作，在大设备量的情况下采用replace会有一定程度的性能提示，毕竟mysql内部的机制能够保证数据的快速操作。
         1.2 在主键不方便选择的情况下，建议采用id作为主键，并设置为自动增长，这样在插入数据库的过程中就能较好的维护主键，能够支持多批量的插入。
         1.3 选择表的合适引擎，在Mysql中Innodb的是行锁，而MyISAM是表锁，但是innodb的插入性能相比MyISAM性能差不少，因此在设计表的过程中需要考虑当前表的使用情况，若插入多，查询少，更新少，则建议采用MyISAM引擎，若更新频繁或者查询频繁，则建议采用Innodb的类型。具体的根据实际情况选择。

经过一系列的处理后，目前性能有了一定的提高，且给出了一些可优化的点，基本算是达标，终于可以解放啦。

这一段时间的工作总算有了个结果，今晚和同事小聚了一下，也算是把一些剩余工作交接一下吧，后天出发回来的地方，南京我要回来啦。