贴一下配置好的logstash配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

input{
	tcp{
		port=>4675
		codec=>json
	}
}

filter{
	mutate{
		gsub=>["message","[\\]",""]
	}
	json{
		source=>"message"
	}
}
output{
	elasticsearch{
		action=>index
		host=>localhost:9092
		index=>"dmp_audit_logs_%{[+YYYY-MM-dd]}"
	}
}

配置中主要分为三部分input、filter、output，这三部分是logstash pipeline中的三个元素，其中input和output是必须的，filter是可选的。

input

配置数据的输入源

控制台输入

ElasticSearch部署

下载解压改配置文件/config/elasticsearch.yml

1
2
3
4
5

cluster.name: my-application
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
cluster.initial_master_nodes: ["node-1"]

启动es命令：

1
2
3

cd /usr/app/elasticSearch
#后台启动
./bin/elasticksearch -d

Kibana部署

下载解压改配置文件/config/kibana.yml：

在一个完整的信息系统里面，日志系统是一个非常重要的功能组成部分。它可以记录下系统所产生的所有行为，并按照某种规范表达出来。我们可以使用日志系统所记录的信息为系统进行排错，优化系统的性能，或者根据这些信息调整系统的行为。在安全领域，日志可以反应出很多的安全攻击行为，比如登录错误，异常访问等。日志还能告诉你很多关于网络中所发生事件的信息，包括性能信息、故障检测和入侵检测。日志会成为在事故发生后查明“发生了什么”的一个很好的“取证”信息来源。日志可以为审计进行审计跟踪。

需求分析

审计日志在哪里执行记录操作？

controller层？service层？dao层？

controller层最先接触到request请求，如果我们要对分析用户的行为，那么日志应该在c层记录

service层是向c层提供服务的，整合了数据访问、数据计算等任务，如果要分析系统服务性能、那么日志应该打在s层

全局ID的要求

• 全局唯一性
• 有序的递增性
• 高可用性
• 时间上的特性

原文链接

所谓热key问题就是，突然有几十万的请求去访问redis上的某个特定key。那么，这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机。
那接下来这个key的请求，就会直接怼到你的数据库上，导致你的服务不可用。

1. 怎么发现热key

方法一:凭借业务经验，进行预估哪些是热key
其实这个方法还是挺有可行性的。比如某商品在做秒杀，那这个商品的key就可以判断出是热key。

缺点很明显，并非所有业务都能预估出哪些key是热key。

方法二:在客户端进行收集
这个方式就是在操作redis之前，加入一行代码进行数据统计。那么这个数据统计的方式有很多种，也可以是给外部的通讯系统发送一个通知信息。缺点就是对客户端代码造成入侵。

先上一张官网的架构图，本文将按照架构图中的组件逐一分析。

1. buffer pool

按照局部性原理，将预期会使用到的数据缓存到内存中，避免每次读取数据都需要进行磁盘i/o，提升i/o性能，这块存放缓存的内存区域就是buffer pool。

buffer pool 是一种降低磁盘访问的机制。

磁盘访问通常以页为单位。

原文链接：https://mp.weixin.qq.com/s/-Hx2KKYMEQCcTC-ADEuwVA

为什么我的事务提交了，还会丢失数据呢？

这要从innoDB的一个参数说起

innodb_flush_log_at_trx_commit

参数的字面意思是innodb在事务提交时更新日志的方式，这个参数有 0，1，2 三种取值，表示有三种方式更新日志

1、单实例安装

1.1、下载redis

下载地址在：redis.io 首页

如果从官网下载慢，可以把链接贴到迅雷下载，再传到虚拟机：

1
2

cd /usr/local/soft/
wget https://download.redis.io/releases/redis-6.0.9.tar.gz

1.2、解压压缩包

1

tar -zxvf redis-6.0.9.tar.gz

1.3、安装gcc依赖

Redis是C语言编写的，编译需要GCC。
Redis6.x.x版本支持了多线程，需要gcc的版本大于4.9，但是CentOS7的默认版本是4.8.5。
查看gcc的版本：

Redis系统介绍：

Redis的基础介绍与安装使用步骤
Redis的基础数据结构与使用
Redis核心原理
Redis 5 之后版本的高可用集群搭建
Redis 5 版本的高可用集群的水平扩展
Redis 5 集群选举原理分析
Redis 5 通信协议解析以及手写一个Jedis客户端

1. 集群方案比较：

1.1 哨兵模式：

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

原文链接

发展史

1、 很久很久以前，Web基本上就是文档的浏览而已，既然是浏览，作为服务器，不需要记录谁在某一段时间里都浏览了什么文 档，每次请求都是一个新的HTTP协议，就是请求加响应，尤其是我不用记住是谁刚刚发了 HTTP请求，每个请求对我来说都是 全新的。这段时间很嗨皮

2、 但是随着交互式Web应用的兴起，像在线购物网站，需要登录的网站等等，马上就面临一个问题，那就是要管理会话，必须记住 哪些人登录系统，哪些人往自己的购物车中放商品，也就是说我必须把每个人区分开，这就是一个不小的挑战，因为HTTP请求是 无状态的，所以想出的办法就是给大家发一个会话标识(session id),说白了就是一个随机的字串，每个人收到的都不一样，每次大 家向我发起HTTP请求的时候，把这个字符串给一并捎过来，这样我就能区分开谁是谁了

3、 这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只需要保存自己的session id，而服务器要保存所有人的session id !如果 访问服务器多了，就得由成千上万，甚至几十万个。这对服务器说是一个巨大的开销，严重的限制了服务器扩展能力，比如说我用两个机器组成了一个集群，小F通过机器A登录了系 统，那session id会保存在机器A上，假设小F的下一次请求被转发到机器B怎么办？机器B可没有小F的session id啊。