随着umc接入主机的数量越来越多，每天产生的syslog日志数量也在剧增， 之前一天产生的syslog数量才不

到1W，随着整个集团的网络设备不端接入，导致现在每天产生的syslog数量大概在180w左右，而这些syslog对

网络和PE同学排查线上网络设备问题又是十分重要的，他们的要求是可以提供查询最近3个月的syslog， 保存一

年的syslog，在7月份的时候，针对量不多的情况，针对mysql单表做了索引，后来又做了单表备份，但是查询的

速度还是无法让人接受，后面又结合页面针对mysqlcount(*)语句做了优化： 使用count(*)语句只是在第一次查询

的时候查询一次，后面保存下来，在后面分页查询的时候，不再需要再查询总数量，即不调用count(*)之类的sql

语句，结果在翻页时，速度还是比较快，但首次查询的时候，还是非常非常慢，但这毕竟只是一个临时的解决方

案；后面结合syslog搜索的业务情况，结合各种技术参考，最终选择了使用Solr搜索引擎来解决syslog查找慢的

问题；

在做压力测试的时候，发现性能问题：在数据量不大(<1000W)的时候，用Solr搜索是比较快，但随着着

syslog数据量的不断增多，写索引和搜索的速度越来越不能让人接受，因此不得不考虑对Solr进行优化；

网上了搜了一下Solr优化的大体方案，主要从如下两个步骤来进行优化：

1.  Solr系统层面；

2.  索引字段优化；

针对Solr系统层的优化，主要有如下的方法：

1. 适当调大Solr查询缓存；

2.适当增加Solr集群的切片；

3根据查询的业务场景，适当调

整索引合并的时间，等等一系列通用的做法，针对这些修改以后，发现修改前后，对查询的性能没有本质

的提高；

针对索引字段的优化，就是针对添加到Lucence中文档各索引字段的优化， syslog索引字段主要的字段有：

id(Integer),

ip(String),

log_level(String),

log_value(String)

syslog_time(Date),

要针对这些字段优索引优化，就要首先分析索引查找的过程，要做到字段优化索引，可以从两方面考虑，

1. 减少字段索引存储量，

2. 提高查询索引比较的时间， 针对这两点，

可以毫不犹豫的考虑把String类型的字段向Integer或Long类型之类的整型字段映射转换(整型的索引存储空间

一般比字段串所占的存储索引空间要小；整型的查找比较速度比字段串类型要快，其实这也是数据库查找优化

的一个方面)；基于这样的考虑，ip、log_level和syslog_time可以向相应的整型映射，各个字段具体的映射方

法如下：

1. ip 地址向整形映射，这个问题比较好解决，在计算机网络协议中，在底层是会把ip地址转换成对应的无

符号长整型，但由于java没有无符号这个概念，因此可以考虑把ip地址向整型或长整型做相互映射转换,但因为

整型比长整型占用的字节更少，因此采用整型，具体转换代码如下：

// 把ip地址转换成整形

1. public static Long ipToInteger(String ip) {
2. String[] ips = StringUtils.split(ip,'.');
3. if (ips == null || ips.length < 4){
4. throw newRuntimeException("ip地址非法!");
5. }
6. Integer integerIP = 0;
7. Integer ip0= Integer.parseInteger(ips[0]);
8. Integer ip1= Integer.parseInteger(ips[1]);
9. Integer ip2= Integer.parseInteger(ips[2]);
10. Integer ip3= Integer.parseInteger(ips[3]);
11. if (ip0 > 255) {
12. throw newRuntimeException("ip0地址非法:" + ip0);
13. }
14. if (ip1 > 255) {
15. throw newRuntimeException("ip1地址非法:" + ip1);
16. }
17. if (ip2 > 255) {
18. throw newRuntimeException("ip2地址非法:" + ip2);
19. }
20. if (ip3 > 255) {
21. throw newRuntimeException("ip3地址非法:" + ip3);
22. }
23. integerIP |=( ip0 << 24) & (0xff000000);
24. integerIP |=( ip1 << 16) & (0x00ff0000);
25. integerIP |=( ip2 << 8) & (0x0000ff00);
26. integerIP |=( ip3 << 0) & (0x000000ff);
27. return integerIP ;
28. }

1. /**
2. * int类型到ip转换
3. * @param integerIP
4. * @return
5. */
6. public static String integerToIP(IntegerintegerIP) {
7. String ip = "";
8. Integer ip0= (integerIP & 0xff000000) >>> 24;
9. Integer ip1= (integerIP & 0x00ff0000) >> 16 ;
10. Integer ip2= (integerIP & 0x0000ff00) >> 8;
11. Integer ip3= (integerIP & 0x000000ff) >> 0;
12. ip = ip0 + "." + ip1 +"." + ip2 + "." + ip3;
13. return ip;
14. }

2. log_level 只有8种值，分别是：Emergency， Alert， Critical， Error， Warning，Notice，Informational，

Debug； 这个好转换，直接按下表的方式做相互映射即可

3. 把syslog_time转换成Long类型，这个更容易，java中Date类型有一个getTime()方法

经过把这三个字段都转换成整型以后，索引插入和搜索速度都提高不少，特别是搜索速度有非常非常明显

的提升，特别是在数据量超过2亿的时间，效果更明显到此，字段优化完毕；

但此时还发现一个问题：一次查找返回的数据量太多，导致存在翻页慢的问题，例如：一次返回10W页数

据，如果一下翻到第10W页，查询的速度会非常非常慢甚至可能出现Solr集群全部宕机的情况，这是不能接受的，

因为我们页面上提供了翻到最后一面的功能， 虽然用户一般情况下不会这么做，但万一不小点错了，整个线上

Sorl集群就全部挂了，怎么办？这个问题，让我想起了mysql里的翻页的问题，下面两条SQL语句：

• select * from umc_syslog where syslog_time between date1 and date2  order by id limit 0, 10;
• select * from umc_syslog where syslog_time between date1 and date2  order by id limit 10000, 10;

我们知道，第一条SQL语句查询的速度非常快，第二SQL语句查询的速度非常慢，在系统压力较大的情况下，

可能会把mysql服务弄挂，根本原因在于limitstart, rows语句，mysql会在扫描时，会扫过满足结果的前start行的

记录，然后才读取len行的数据，如果start特别大，会非常慢，在高性能mysql这本书中介绍了各种解决分页问

题的优化，如延迟关联、阶递分页等，其中阶递分页可以在Solr中实现，但我们页面不允许这么做，不然早就

用Hbase来解决了，怎么办，在无解决的情况下，突然发现，Solr查询中有order by排序的问题，适当用order by

可以很好来解决limit 分页慢的问题：

假设 一个Solr查询按id 降序排序返回，假设返回10W行记录，前5W条记录可以随机分页查询到，但后面

5W条记录很难随机分页查询到，造成这个问题的原因是按id降序返回，如果适当修改一下查询语句，速度可

能会有所提高，因为Solr查询每次都会返回总的记录条数，这个总的记录条数是已知的， 记为total, 作如下处

理：如果start 小于等于 （total >> 1）,则从前往后读；否则就从后往前读，然后，再把返回的结果逆序，显示

即可，伪代码如下；

1. if start <= (total >> 1)
2. query order by id desc limit start, rows;
3. else
4. calculate new start as start';
5. calculate new rows as rows';
6. query order by asc limit start', rows';
7. reverse the return data;
8. end

程序中相关代码：

1. // 是否是按id升序查询, 默认是false
2. boolean isAscend = false;
3. // 升序或降序查询判断
4. if (totalCount == 0) {
5. isAscend = false;
6. } else {
7. if (start >= (totalCount >> 1) ) {
8. isAscend = true;
9. }
10. }
11. if (!isAscend) {
12. realStart = start;
13. realRows = rows;
14. } else {
15. Integer count = totalCount.intValue();
16. realStart = (start + rows)>= count? 0 : (count - (start +rows));
17. realRows = (start + rows)>= count? (count - start + 1) : rows;
18. }
19. solrQuery.setStart(realStart);
20. solrQuery.setRows(realRows);
21. if (!isAscend) {// id降序
22. solrQuery.setSort("id", ORDER.desc);
23. } else { // id 升序
24. solrQuery.setSort("id", ORDER.asc);
25. }
26. // 逆序处理
27. if (isAscend) {
28. int size = syslogVOList.size();
29. int left = 0;
30. int right = size - 1;
31. while (left < right) {
32. SyslogVO leftSyslogVO =syslogVOList.get(left);
33. SyslogVO rightSyslogVO =syslogVOList.get(right);
34. syslogVOList.set(left, rightSyslogVO);
35. syslogVOList.set(right, leftSyslogVO);
36. left ++;
37. right --;
38. }
39. }

经过这个过程的处理之后，向后翻页查询的速度快了很多，至少不会出现宕机的现象；

查询页面如下：

在相同的条件下：

优化后Solr查询的时间：

优化前mysql的查询时间：

其实这个技巧在mysql分页查询，数据量非常大的时候也适用；