日志提取分析工具(java源码)

最近有个项目,是硬件结合的,硬件上传到服务器的日志,每天数百万条,有时候某个设备出问题了,因为日志的数据很混乱,很难查出具体的原因。

所以写了这个工具,主要是提高日志分析的效率,可以通过关键词提取日志数据。

工具使用了多线程、I/O等技术,本人技术有限,所以只能写到这样子,测试过很多次。

测试出来的数据:400MB的日志,5个线程:96~97秒完成分割,分割出来的日志大小大同小异,为什么不把分割出来的日志合并呢?因为线程的启动时间不是顺序的,加上本人懒,所以没做了。

不建议使用超过20个线程去处理日志。因为如果是2GB的数据,10个线程去处理,每个线程也只需要处理204.8MB。这个已经是非常快的效率了。

Redis内存淘汰机制

Redis内存淘汰指的是用户存储的一些key可以被Redis主动地从实例中删除,从而产生读miss的情况,那么Redis为什么要有这种功能?

这就是我们需要探究的设计初衷,Redis最常见的两种应用场景为缓存和持久存储,首先要明确的一个问题是内存淘汰策略更适合于那种场景?是持久存储还是缓存?

内存的淘汰机制的初衷是为了更好地使用内存,用一定的缓存miss来换取内存的使用效率。

redis 官方提供的 conf

https://raw.github.com/antirez/redis/2.2/redis.conf

1.# maxmemory <bytes>

我们可以通过配置redis.conf中的maxmemory这个值来开启内存淘汰功能,至于这个值有什么意义,我们可以通过了解内存淘汰的过程来理解它的意义:

1. 客户端发起了需要申请更多内存的命令(如set)。

2. Redis检查内存使用情况,如果已使用的内存大于maxmemory则开始根据用户配置的不同淘汰策略来淘汰内存(key),从而换取一定的内存。

3. 如果上面都没问题,则这个命令执行成功。

 

2.# maxmemory-policy volatile-lru

redis 中的默认的过期策略是 volatile-lru 。

设置方式   

config set maxmemory-policy volatile-lru

maxmemory-policy 六种方式:

#volatile-lru – >使用LRU算法删除使用过期集合的key
#allkeys-lru – >在主键空间中,优先移除最近未使用的key。
#volatile-random – >在设置了过期时间的键空间中,随机移除某个key。
#allkeys-random – >在主键空间中,随机移除某个key。
#volatile-ttl – >设置了过期时间的键空间中,具有更早过期时间的key优先移除。
#novaiction – >当内存使用达到阈值的时候,所有引起申请内存的命令会报错。

 

 

Push to origin/master was rejected

错误如下:

Git Pull Failed: fatal: refusing to merge unrelated histories

意思是git拒绝合并两个不相干的东西
此时你需要在打开Git Bash,然后进入相应的目录,然后敲git命令:

$ git pull origin master --allow-unrelated-histories

出现类似于这种信息就说明pull成功了:

$ git pull origin master --allow-unrelated-histories
From gitee.com:alanro/suisuinian__server
 * branch master -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 LICENSE | 191 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 191 insertions(+)
 create mode 100644 LICENSE

然后你可以利用git status查看一下当前仓库的状态,是不是所有的全部add并且commit,如果全部完成,那么此时你就可以将本地仓库中的推送到github中,使用如下的git命令:

$ git push -u origin master

搞定

美团点评数据库高可用架构的演进与设想

本文介绍最近几年美团点评MySQL数据库高可用架构的演进过程,以及我们在开源技术基础上做的一些创新。同时,也和业界其它方案进行综合对比,了解业界在高可用方面的进展,和未来我们的一些规划和展望。

MMM

在2015年之前,美团点评(点评侧)长期使用MMM(Master-Master replication manager for MySQL)做数据库高可用,积累了比较多的经验,也踩了不少坑,可以说MMM在公司数据库高速发展过程中起到了很大的作用。

Kafka与Zookeeper常用操作

一、Kafka操作

1.启动kafka命令:

#cd /opt/kafka_2.10-0.10.1.1/bin;

# ./kafka-server-start.sh /opt/kafka_2.10-0.10.1.1/config/server.properties &;

2.停止kafka命令:

# ./kafka-server-stop.sh

3.创建Topic:(创建一个名为test的topic,只有一个副本,一个分区。)

#./kafka-topics.sh –create –zookeeper 127.0.0.1:2181 –replication-factor 1 –partitions 1 –topic test

4.列出所有Topic:

#./kafka-topics.sh -list -zookeeper 127.0.0.1:2181

5.启动Producer并发送消息:

#./kafka-console-producer.sh –broker-list localhost:9092 –topic test

(输入相应的消息,eg:hello kafka;按Ctrl+C结束)

6.启动Consumer并接收消息:

#./kafka-console-consumer.sh –zookeeper 127.0.0.1:2181 –topic test –from-beginning

7.前台启动kafka:

./kafka-server-start.sh ../config/server.properties

8.后台启动kafka:

./kafka-server-start.sh ../config/server.properties 1>/dev/null 2>&1 &

9.指定监听端口

JMX_PORT=2898

./kafka-server-start.sh ../config/server.properties 1>/dev/null 2>&1 &

 

二、Zookeeper常用操作

1.Zookeeper服务端启动:

# cd /opt/zookeeper-3.4.10/bin/

#./zkServer.sh start

2.Zookeeper服务端停止:

# cd /opt/zookeeper-3.4.10/bin/

#./zkServer.sh stop

3.Zookeeper服务端重启:

# cd /opt/zookeeper-3.4.10/bin/

#./zkServer.sh restart

4.查看Zookeeper进程:

#ps -ef|grep zookeeper;

5.查看Zookeeper服务端状态:

# cd /opt/zookeeper-3.4.10/bin/

#./zkServer.sh status

6.Zookeeper客户端登陆:

# cd /opt/zookeeper-3.4.10/bin/

#./zkCli.sh -server 127.0.0.1:2181

 

123417