作者归档：Young

尝试LeetCode

发表回复

起因

OJ在学生时代应该都有所接触，作为程序设计与算法课程的实践内容也在一些OJ上做过少数的一些题目。不得不说，多年的习惯让在OJ上解题成为了一件很愉悦的事情。

工作后，原本薄弱的算法知识感觉消失殆尽，尽管在每天的工作中，组装、修改成为了工作的主题，可是总觉得自己不应如此，希望自己能保持毕业前那样积极的学习态度，希望自己能把之前的自主学习和思考的习惯保持下来。然而自己在每天的工作之后，惰性还是占了上风，阅读自然不少，可是这类基础的训练却扔下了。

本科期间由于学校身边的环境的缘故，自学了Java的基础编程。这半年对Android开发很感兴趣，再次接触Java，自己实现的过程中，感觉自己再次的丢掉了很多东西。

工作两年，经历了最开始的模仿、学习阶段之后，也尝试了各个方向，单独承担系统的开发维护工作中，更是觉得基础的知识，诸如网络、OS等基础知识在解决问题上能对思路起到打磨的作用，避免自己掉进 case by case 的坑里。积累经验当然重要，但是个人觉得更难得的是学会如何找到解决问题的方式，面向StackOverflow编程并不是一个好的选择。

近期看到 云风 大牛的关于反转单向链表微博，自己下班尝试编写了一下，也是花了一会儿时间才能顺畅的写完。这两天也是看到liaohuqiu 大牛发起的 LeetCode攻克计划，觉得是时候重新开始修行了。

目的

刷 LeetCode 的目的主要有两个：

  • 从基础开始，重新学习Java编程
  • 重新学习算法知识

第一个理由可能引人发笑，然而这确实是一个手段。自己在学习编写Java程序的过程中曾经过分的贪图速度，跳过了很多自认为基础的语言上的内容，在比较自己编写的代码与熟练的同事的代码中，更能有所体会。

计划

基于第一个原因，所有的LeetCode解题都会使用Java完成。

目前来看，一共有83道 Easy 题目，167道 Medium 题目，以及74道 Hard 题目。

不求过分贪心，希望半年内，我能把所有的 Easy 完成。

对于解决的题目，将会在blog里贴出自己的解题方案以及简要的解题思路，同时在解题过程中，尽量通过完备自己的思路和case解决问题，而不是通过尝试AC来解决问题。

已解决问题 [2]

two-sum Easy

add-two-numbers Medium

查看MySQL LOAD DATA进度

发表回复

概述

开发过程中经常会使用MySQL的LOAD DATA功能，用于导入文件到MySQL的指定数据库表中。

若已经将文件切分为N个小文件再进行LOAD操作（例如使用Linux下的 split 工具），那么进度还是很容易把控的，可以通过直接查找当前正在进行导入的分片，进而判断当前的分片。

可是，如果某些情况下直接对一个大型的文件进行进行LOAD操作，整个过程并不能直观的获取当前的进度的，需要通过一些相对曲折的过程才能获取当前LOAD的进度。

分析

/proc虚拟文件系统

Linux中的/proc虚拟文件系统是一个非常有趣的部分，这一个目录并不是包含了一些常规意义上的文件，而是表征了进程的部分运行时信息。部分Linux工具更是可以直接用读取目录中的部分信息来替代[1]。

在/proc下可以看到大量的名为数字的目录，这些数字正是进程的pid。而cd到其中任何一个目录下，可以看到类似的信息：

各个目录的说明可以参考此处。

/proc下的fdinfo

这里我们关注的地方是如何通过这些丰富的信息获取导入数据库的进度。

考虑到这一导入操作，实际上是利用了MySQL进行读取文件的操作，那么，只需要知道MySQL当前读取的文件位置，就可以了解到当前的进度了。

/proc/[PID]/fdinfo/这一目录正是解决这一问题的关键，这一目录包含了当前进程已打开的文件的信息，其中文件名正是文件描述符的名称，而相关信息则存储在这个只读文件之中。包含的信息形如：

pos

pos即文件读取游标的偏移值，也就是我们关注的已读取到的位置。

flags

flags则是一个八进制数，表征当前文件的打开状态。

以上述打开的文件为例，这是一个Nginx打开的日志文件，通过lsof +fg -p [PID]可以看到这一文件打开使用的flag：

可以看到使用了W、AP、LG三个flag，而W对应的是O_WRONLY，AP对应的是O_APPEND，LG对应的的O_LARGEFILE，这三个常量的值一般可以在/usr/include/bits/fcntl.h中找到：

所以flags的值为何是0102001也可以解释了。

获取进度

根据上述分析，首先我们直接找到正在进行LOAD操作的MySQL进程的PID，获取之后查看当前打开的文件（假设文件名为foo）在进程中的fd：

获取fd之后，直接读取对应的fdinfo：

根据pos可以知道当前已读取了的文件位置，进而获知LOAD进度。

以上。

一组PHP7在Nginx与Apache下的测试数据

发表回复

概述

PHP7作为迄今为止性能最强的PHP版本，希望通过一些测试来了解它在Nginx与Apache下的表现。数据仅供参考。

由于个人水平有限，对测试的理解可能有所偏差，如有错误麻烦指出。

运行环境

测试环境一共分为两台机器，机器A用作PHP运行环境，机器B作为压测机。A与B的CPU均为12 x Xeon E5 + 16GB RAM。

两台机器位于同一网段。

测试工具使用ab。

为了便于测试，调整了内核参数：

测试使用的软件版本为：

  • Apache 2.2
  • Nginx 1.2.7
  • PHP 7.0.4

Apache在httpd-mpm.conf中的配置为：

由于Apache+modphp7与Nginx+PHP-FPM二者的工作模式差别较大，想要均衡的配置出一个均衡的测试比较环境很困难，从简单出发，考虑到Apache在上述配置下最大会fork出512个进程处理请求，将PHP-FPM最大进程数也设成512个，即:

测试方法

测试主要针对三种操作进行：输出Hello World，Redis KV读取操作，输出phpinfo()。

选择Redis KV读取操作的目的主要想测试下这一常用扩展的在Apache与Nginx作为WebServer环境下的表现。

测试分为2组，分别在25并发以及512并发下进行，测试时长为1min，同时记录服务器的load情况。

关注的数据为：

  • 最小响应时间
  • 平均响应时间
  • 平均每秒请求数
  • load
  • 相关进程数

测试结果

测试从性能指标以及系统负载两个方面进行观察。

性能指标

最小响应时间

min_response_time.png

针对最小响应时间，并发数高低对最小响应时间没有显著的影响。在测试初期系统负载较低，测试数据应该表现最佳的阶段，推断二者在此阶段差距不大。

平均每秒请求数

requests_per_sec.png

针对平均每秒请求数，Nginx+PHP-FPM的组合处理能力稍低于Apache+modphp7的组合，考虑到Nginx与PHP-FPM之间有网络通信(测试中采用了tcp socket)的开销，这个结果是可以接受的。高并发下考虑系统开销较大，请求处理能力会稍有下降。

平均响应时间

mean_response_time.png

针对平均响应时间，高并发下同样由于系统开销较大的缘故，平均的请求处理响应时间升高也是符合预期的。

系统负载

从性能指标上看，Nginx+PHP-FPM的组合与Apache+modphp7的组合在表现上没有巨大的差距，但是在系统负载上，Nginx+PHP-FPM的配置在高并发的情况下远优于Apache+modphp7的组合。 在512并发时，在测试Hello world时，系统load的表现就有巨大的差距：

load_hello_world.png

同样的情况还出现在512并发之下对Redis KV操作的测试case之下：

load_redis_kv.png

即便是在低并发（25并发）下，Redis KV此类需要操作网络资源的操作，Apache+modphp7在系统负载上的表现也差于Nginx+PHP-FPM：

load_redis_kv_c25.png

对于这类需要操作I/O的操作来说，Apache+modphp7的组合表现差于使用了异步I/O的Nginx与PHP-FPM的组合是符合预期的。

在测试phpinfo()输出时，虽然二者在load上的区别不大，但是Nginx+PHP-FPM的组合在进程数这一指标上完全占优：

processes_count_phpinfo.png

考虑到Nginx+PHP-FPM的组合无需fork出新的子进程处理新到的客户端请求，以及phpinfo()的执行时间较长这两个因素，同时fork子进程等操作属于消耗系统资源较大的操作，这个现象是符合预期的。

总结

使用php7时，在性能上Apache+modphp7的组合与Nginx+PHP-FPM的组合相差无几，但对于系统负载上来说，Nginx+PHP-FPM组合综合表现优于Apache+modephp7的组合，可以推断Nginx+PHP-FPM的组合对于构建高并发的服务更有优势。

综合考虑，Nginx+PHP-FPM表现较优。

TODO

  • 尝试阅读ab源码，了解其测试原理
  • 比对fpm在动静模式之间的区别

一组Logstash与elasticsearch的压测数据

发表回复

概述

组内的日志系统基于ELK搭建，本文中的数据在生产环境中进行测试得到，仅供参考。

系统构成

系统可以简要的分为：

  • 日志接收机
  • 日志数据队列
  • 日志数据处理机
  • ES集群

在日志接收机上通过一个 Logstash 进程 parse 日志数据，将 parse 后的结构写入由 Redis List 实现的日志数据队列中，之后在ES集群前，再使用一个日志处理机 Logstash 进程从 Redis 中 pop 出数据写入ES集群中。

使用 Redis List 的原因是在于当 parse 能力大于ES集群的处理能力时，缓存数据。

运行环境

日志接收机为CPU为4 * Xeon E5强IO型机器，Redis List 与向ES集群写入的 Logstash 位于同一机器上，即日志数据处理机，CPU为12 * Xeon E5。

处理日志为Nginx access日志，记录了如时间、域名、访问IP、URL、HTTP Method、响应时间、返回体长度等，约10+字段。

参数配置

日志接收机上的 Logstash 配置成了10个线程，output 中的 redis 的参数配置为：

日志数据处理机上的 input 对已配置为：

而 output 配置为：

测试方法

测试分为测试 Logstash 分析日志能力，以及ES集群写入能力。

Logstash 的分析能力通过每秒取样 Redis List 中的新增队列长度获得（日志接收机上的 Logstash 生产）。

ES集群的写入能力通过每秒取样 Redis List 中减少的队列长度获得（日志数据处理机 上的 Logstash 消费）。

在测试一个阶段时，会关闭另一端的 Logstash。

数据

平均数据后，可供参考的数据为：

Logstash 分析速度为：2352.94 lines/s

ES集群写入速度为：9345.79 records/s

自定义Nagios报警脚本

发表回复

概述

Nagios可以使用邮件报警，但是如果使用IM软件提供的API进行报警的话，时效性上来说必然是会更好的。

另外如果使用自定义的报警脚本，可以针对报警做更多的事情，譬如限频，异步发送，记录入库等操作。

总而言之就是可以拥有更为灵活的工具。

关键点

开发语言

众多的Nagios插件均使用Perl编写，如 监控Redis 中使用到的工具。

选用Perl语言对于我来说并不是一个好的选择，如果选用了Perl，那么在主要使用PHP的环境下，不能方便的重复利用已有框架的各种工具，同时从语言的熟悉程度上来说，自然是PHP胜过Perl。

综上，选用PHP作为插件开发语言。

选用PHP作为Nagios报警插件的开发语言，需要在脚本的首行指定 Shebang ，即指定PHP可执行程序的绝对路径，形如：

Shebang之下仍然需要使用 <?php 标签。

同时，为了能让Nagios能直接执行报警插件，需要赋予可执行权限：

脚本输入输出

输入

脚本的输入方式与普通的命令行工具并无太多区别，可以使用 getopt 来获取输入的参数。

由于需要实现限频，以及针对主机和服务做一些处理，定义了如下的参数：

参数 说明
u 通知用户
m 报警消息体
r 频率限制值，秒为单位
h 主机
p 端口
l 通知等级，即OK/CRITICAL/WARNING/UNKNOW等
n 通知类型，即PROBLEM/CUSTOM等

限频的目的在于防止接收过多信息，避免必须处理的信息无法及时被发现。

而针对服务恢复正常的信息，不需要限频。

输出

Nagios的插件通过返回值确定这次检验的状态，即：

Exit code 状态
0 OK
1 WARNING
2 CRITICAL
3 UNKNOWN

不过由于是报警脚本，不妨直接让脚本返回0吧。

自定义变量

Nagios在调用编写的报警脚本时，通过定义好的command格式，完成传参。

对应到每一个联系人，需要有变量告知联系人的联系方式，针对IM，比如QQ，自然是QQ号。查阅Nagios预定义宏，会发现并没有QQ号这样的预定义宏。

当然可以选用预定义的 CONTACTPAGER 。考虑到寻呼机已经几乎没人使用了，可以借用一下变量。

针对各种工具（IM/内部通信接口/短信平台接口等），需要自定义。

关于自定义，Nagios的文档已有说明，这里简单提及一下：

  • 自定义变量必须以_开头以防止与预定义变量冲突
  • 自定义变量使用时需要转为全大写
  • 自定义变量会在前方加上所属的对象类型

针对第三点，简单说来，针对Contact，即联系人这一对象，如果定义了名为uid的自定义变量，那么，在contact的配置中，需要写成_uid，而实际在配置command时，会变为$_CONTACTUID$。

配置commands

新增一个发送报警命令send_pm，定义这一自定义报警的调用方式。

参数列表正如上文提及的。

报警内容为了简短，只会发送主机名、服务名称以及检查结果的首行。

配置contacts

在需要报警的联系人配置中，加上自定义的uid变量，以及指定报警方法：

以上。