附带要求：
1、了解并配置服务器的最大文件操作数

Linux 服务器 设置最大打开文件数永久

vim /etc/security/limits.conf

* soft nofile 65535

* hard nofile 65535

注意“”是要加到文件里面的。这两句话的含义是 soft（应用软件）级别限制的最大可打开文件数的限制，hard 表示操作系统级别限制的最大可打开文件数的限制，“”表示所有用户都生效。保存这个文件（只有 root 用户能够有权限）。

执行命令后，配置马上生效。您可以用 ulimit -a 查看目前会话中的所有核心配置

 

ulimit 是一个计算机命令，用于 shell 启动进程所占用的资源，可用于修改系统资源限制

命令常用参数

 

 

2、安装 tengine 并配置负载和后端节点检查，但是要求了解 nginx 与 tengine 基本区别

 

nginx 和 tengine 的区别是：

1、tengine 是在 nginx 上面开发的，包含了 nginx 的性能。

2、tengine 更适合大访问量网站的需求，相比 nginx 更加的稳定，性能更加的强劲。

据网络测试：

Tengine 相比 Nginx 默认配置，提升 200% 的处理能力。
Tengine 相比 Nginx 优化配置，提升 60% 的处理能力。

 

 

vim nginx.conf

server {

  location /status {

    check_status;

 # 访问日志 结束

    access_log off;

#允许一些。ip。地址

    allow SOME.IP.ADDRESS

#禁止所有
#全部拒绝
#拒绝所有

    deny all;

  }

}

 

 

在 upstream 配置如下
check interval=3000 rise=2 fall=5 timeout=1000 type=http;

 

 

interval 表示每隔 3000 毫秒向后端发送健康检查包 

rise 表示如果连续成功次数达到 2 服务器就被认为是 up 

fail 表示如果连续失败次数达到 5 服务器就被认为是 down

timeout 表示后端健康请求的超时时间是 1000 毫秒 

type 表示发送的健康检查包是 http 请求

#检查间隔 =3000 上升 =2 下降 =5 超时 =1000 类型 =http;
check_http_send"HEAD / HTTP/1.0\r\n\r\n";

检查 http 发送头
check_http_expect_alivehttp_2xx http_3xx;

#check_http 期望 alivehttp

 

 

 

 

check_http_send 表示 http 健康检查包发送的请求内容。为了减少传输数据量，推荐采用“head”方法

第 45 行

check_http_expect_alive 指定 HTTP 回复的成功状态，默认认为 2XX 和 3XX 的状态是健康的。

 

 

 

* 关闭服务

# sbin/nginx -s stop

* 重新加载配置项

# sbin/nginx -s reload

* 校验 conf 文件夹中 nginx.conf 文件格式是否正确

# sbin/nginx -t

* 帮助命令

# sbin/nginx -h

 

 

配置 nginx.conf

vim nginx.conf

server {

  location /status {

    check_status;

 

    access_log off;

    allow SOME.IP.ADDRESS

    deny all;

  }

}

在 upstream 配置如下
check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send"HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alivehttp_2xx http_3xx;

3、MySQL 有几种安装方式，分别怎么安装和卸载，主要进行解压通用版本安装，并且了解 mysql 中比较常用的命令

安装

yum - y install mysql-servse

• 1

启动 mysql 服务

service mysqld start
运行端口为3306

• 1
• 2

登陆

mysql -uroot

• 1

语法 ：mysql -u 账号 -p 密码
默认是空密码

库和表

层次关系
库--> 表
create database  库名；创建一个库
show database；查看有哪些库
use 库名；进入这个库
show tables；查看表

• 1
• 2
• 3
• 4
• 5
• 6

创建表

CREATE TABLE fruits(
	f_id CHAR(10) PRIMARY KEY,
	s_id INT NOT NULL,
	f_name char(255) NOT NULL,
	f_price DECIMAL(8,2) NOT NULL,
);

• 1
• 2
• 3
• 4
• 5
• 6

语法 CREATE TABLE 表名（
列名 类型，约束条件，
）；
后面要用，隔开
内容如图所示

添加数据

INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('a1',101,'apple',5.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price)VALUES('b1',101,'blackberry',10.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('bs1',102,'orange',11.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('bs2',105,'melon',8.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('t1',102,'banana',10.3);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('t2',102,'grape', 5.3);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('o2',103,'coconut',9.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('c0',101,'cherry',3.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('a2',103,'apricot',2.2);
INSERT INTO fruits(f_id,s_id,f_name,f_price) VALUES('l2',104,'lemon',6.4);

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

格式：
INSERT INTO 表名 (列 1，列 2，列 3) VALUES(值 1，值 2，值 3);
如果值的类型是字符型需要加引号。

更新表

uodate fruits set f_name='sss' where s_id=‘101’ ；

• 1

删除表

delete  from  fruits where  s_id=‘102’； 

• 1

查询 ( 以刚才创建的表为例）

查询所有字段

select * from fruits

• 1

查询制定字段

select * from fruits where f_name='apple'

• 1

带 IN 关键字查询

IN(aa，bb）满足条件范围内的一个值即可匹配。
select * from fruits where f_name IN （'apple‘，’orange‘）

• 1
• 2

between and 范围查询用法

select * from fruits where f_price between 5 and 15;
查询价格在5到15之间的全部信息

• 1
• 2

空值查询

SELECT * FROM 表名 WHERE 字段名 IS NULL;
//查询字段名是NULL的记录
SELECT * FROM 表名 WHERE 字段名 IS NOT NULL;
//查询字段名不是NULL的记录

• 1
• 2
• 3
• 4

带 AND 的多条件查询

selcet * from fruits where s_id=101 and f_price>5;

• 1

带 or 的多条件查询

selcet * from fruits where s_id=101 or f_price>5;

• 1

关键字 DISTINCT(查询结果不重复)

select  distinct s_id from fruits;

• 1

对查询结果排序（order by）

select  distinct s_id from fruits order by s_id;
通过s_id进行排序，默认升序
select  distinct s_id from fruits order by s_id desc;
降序排列

• 1
• 2
• 3
• 4

分组查询（group by）

s_id,count(f_name),group_concat(f_name) from fruits group by s_id;
对分组过后的结果可以进行having过滤
select s_id,count(f_name),group_concat(f_name)
 from fruits group by s_id having count(f_name) > 1

• 1
• 2
• 3
• 4

limit 限制查询结果的数量

select * from fruits limit 4;

• 1

集合函数查询

select conut（*） from fruits;
select SUM(f_price）from fruits；
select AVG(f_price）from fruits；
select MAX(f_price）from fruits；
select MIN(f_price）from fruits；

• 1
• 2
• 3
• 4
• 5

多表查询

select s.s_id,s.s_name,f.f_name,f.f_id
from 表一 as s ,表二 as f
where f.s_id = s.s_id
//fruits 和 suppliers 为表名

• 1
• 2
• 3
• 4

表一用 s 表示，表二用 f 表示

内连查询 inner join 表名 on 连接条件

select s.s_id,s.s_name,f.f_name,f.f_id
from 表一 as s   INER JOIN表二 as f
ON f.s_id = s.s_id

• 1
• 2
• 3

4、redis 的密码和持久化设置，redis 基本操作命令了解，info 信息基本解读

find / -name dump.rdb

find / -name  redis.conf

   众所周知，redis 是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当 redis 所在服务器发生宕机后，redis 数据库里的所有数据将会全部丢失。

为了解决这个问题，redis 提供了持久化功能——RDB 和 AOF。通俗的讲就是将内存中的数据写入硬盘中。

     一、持久化之全量写入：RDB

 

redis 是一款开源的、高性能的键 - 值存储（key-value store），和 memcached 类似，redis 常被称作是一款 key-value 内存存储系统或者内存数据库，同时由于它支持丰富的数据结构，又被称为一种数据结构服务器（data structure server）。

编译完 redis，它的配置文件在源码目录下 redis.conf  ，将其拷贝到工作目录下即可使用，下面具体解释 redis.conf 中的各个参数：

 

1 daemonize  no

默认情况下，redis 不是在后台运行的，如果需要在后台运行，把该项的值更改为 yes。

2 pidfile  /var/run/redis.pid

当 Redis 在后台运行的时候，Redis 默认会把 pid 文件放在 /var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口

3 port

监听端口，默认为 6379

4 #bind 127.0.0.1

指定 Redis 只接收来自于该 IP 地址的请求，如果不进行设置，那么将处理所有请求，在生产环境中为了安全最好设置该项。默认注释掉，不开启

5 timeout 0

设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接

6 tcp-keepalive 0

指定 TCP 连接是否为长连接,"侦探" 信号有 server 端维护。默认为 0. 表示禁用

7 loglevel notice

log 等级分为 4 级，debug,verbose, notice, 和 warning。生产环境下一般开启 notice

8 logfile stdout

配置 log 文件地址，默认使用标准输出，即打印在命令行终端的窗口上，修改为日志文件目录

9 databases 16

设置数据库的个数，可以使用 SELECT 命令来切换数据库。默认使用的数据库是 0 号库。默认 16 个库

10 

save 900 1
save 300 10
save 60 10000

保存数据快照的频率，即将数据持久化到 dump.rdb 文件中的频度。用来描述 "在多少秒期间至少多少个变更操作" 触发 snapshot 数据保存动作

 

默认设置，意思是：

if(在 60 秒之内有 10000 个 keys 发生变化时){

进行镜像备份

}else if(在 300 秒之内有 10 个 keys 发生了变化){

进行镜像备份

}else if(在 900 秒之内有 1 个 keys 发生了变化){

进行镜像备份

}

11 stop-writes-on-bgsave-error yes

当持久化出现错误时，是否依然继续进行工作，是否终止所有的客户端 write 请求。默认设置 "yes" 表示终止，一旦 snapshot 数据保存故障，那么此 server 为只读服务。如果为 "no"，那么此次 snapshot 将失败，但下一次 snapshot 不会受到影响，不过如果出现故障, 数据只能恢复到 "最近一个成功点"

12 rdbcompression yes

在进行数据镜像备份时，是否启用 rdb 文件压缩手段，默认为 yes。压缩可能需要额外的 cpu 开支，不过这能够有效的减小 rdb 文件的大，有利于存储 / 备份 / 传输 / 数据恢复

13 rdbchecksum yes

读取和写入时候，会损失 10% 性能

14 rdbchecksum yes

是否进行校验和，是否对 rdb 文件使用 CRC64 校验和, 默认为 "yes"，那么每个 rdb 文件内容的末尾都会追加 CRC 校验和，利于第三方校验工具检测文件完整性

14 dbfilename dump.rdb

镜像备份文件的文件名，默认为 dump.rdb

15 dir ./

数据库镜像备份的文件 rdb/AOF 文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中

16 # slaveof <masterip> <masterport>

设置该数据库为其他数据库的从数据库，并为其指定 master 信息。

17 masterauth

当主数据库连接需要密码验证时，在这里指定

18 slave-serve-stale-data yes

当主 master 服务器挂机或主从复制在进行时，是否依然可以允许客户访问可能过期的数据。在 "yes" 情况下,slave 继续向客户端提供只读服务, 有可能此时的数据已经过期；在 "no" 情况下，任何向此 server 发送的数据请求服务 (包括客户端和此 server 的 slave) 都将被告知 "error"

19 slave-read-only yes

slave 是否为 "只读"，强烈建议为 "yes"

20 # repl-ping-slave-period 10

slave 向指定的 master 发送 ping 消息的时间间隔 (秒)，默认为 10

21 # repl-timeout 60

slave 与 master 通讯中, 最大空闲时间, 默认 60 秒. 超时将导致连接关闭

22 repl-disable-tcp-nodelay no

slave 与 master 的连接, 是否禁用 TCP nodelay 选项。"yes" 表示禁用, 那么 socket 通讯中数据将会以 packet 方式发送 (packet 大小受到 socket buffer 限制)。

可以提高 socket 通讯的效率 (tcp 交互次数), 但是小数据将会被 buffer, 不会被立即发送, 对于接受者可能存在延迟。"no" 表示开启 tcp nodelay 选项, 任何数据都会被立即发送, 及时性较好, 但是效率较低，建议设为 no

23 slave-priority 100

适用 Sentinel 模块 (unstable,M-S 集群管理和监控), 需要额外的配置文件支持。slave 的权重值, 默认 100. 当 master 失效后,Sentinel 将会从 slave 列表中找到权重值最低(>0) 的 slave, 并提升为 master。如果权重值为 0, 表示此 slave 为 "观察者", 不参与 master 选举

24 # requirepass foobared

设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为 redis 速度相当快，所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行 150K 次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。

25 # rename-command CONFIG 3ed984507a5dcd722aeade310065ce5d    (方式:MD5('CONFIG^!'))

重命名指令, 对于一些与 "server" 控制有关的指令, 可能不希望远程客户端 (非管理员用户) 链接随意使用, 那么就可以把这些指令重命名为 "难以阅读" 的其他字符串

26 # maxclients 10000

 

限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求，客户端尝试连接时将收到 error 信息。默认为 10000，要考虑系统文件描述符限制，不宜过大，浪费文件描述符，具体多少根据具体情况而定

27 # maxmemory <bytes>

redis-cache 所能使用的最大内存 (bytes), 默认为 0, 表示 "无限制", 最终由 OS 物理内存大小决定(如果物理内存不足, 有可能会使用 swap)。此值尽量不要超过机器的物理内存尺寸, 从性能和实施的角度考虑, 可以为物理内存 3/4。此配置需要和 "maxmemory-policy" 配合使用, 当 redis 中内存数据达到 maxmemory 时, 触发 "清除策略"。在 "内存不足" 时, 任何 write 操作(比如 set,lpush 等) 都会触发 "清除策略" 的执行。在实际环境中, 建议 redis 的所有物理机器的硬件配置保持一致(内存一致), 同时确保 master/slave 中 "maxmemory""policy" 配置一致。

当内存满了的时候，如果还接收到 set 命令，redis 将先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。在删除时，

将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息的 key 都删光了，内存还不够用，那么将返回错误。这样，redis 将不再接收写请求，只接收 get 请求。maxmemory 的设置比较适合于把 redis 当作于类似 memcached 的缓存来使用。

28 # maxmemory-policy volatile-lru

内存不足 "时, 数据清除策略, 默认为"volatile-lru"。

volatile-lru  -> 对 "过期集合" 中的数据采取 LRU(近期最少使用) 算法. 如果对 key 使用 "expire" 指令指定了过期时间, 那么此 key 将会被添加到 "过期集合" 中。将已经过期 /LRU 的数据优先移除. 如果 "过期集合" 中全部移除仍不能满足内存需求, 将 OOM.
allkeys-lru -> 对所有的数据, 采用 LRU 算法
volatile-random -> 对 "过期集合" 中的数据采取 "随即选取" 算法, 并移除选中的 K-V, 直到 "内存足够" 为止. 如果如果 "过期集合" 中全部移除全部移除仍不能满足, 将 OOM
allkeys-random -> 对所有的数据, 采取 "随机选取" 算法, 并移除选中的 K-V, 直到 "内存足够" 为止
volatile-ttl -> 对 "过期集合" 中的数据采取 TTL 算法 (最小存活时间), 移除即将过期的数据.
noeviction -> 不做任何干扰操作, 直接返回 OOM 异常
另外，如果数据的过期不会对 "应用系统" 带来异常, 且系统中 write 操作比较密集, 建议采取 "allkeys-lru"

29 # maxmemory-samples 3

默认值 3，上面 LRU 和最小 TTL 策略并非严谨的策略，而是大约估算的方式，因此可以选择取样值以便检查

29 appendonly no

默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁。所以 redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。开启 append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到 appendonly.aof 文件中，当 redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成 appendonly.aof 文件过大，所以 redis 还支持了 BGREWRITEAOF 指令，对 appendonly.aof 进行重新整理。如果不经常进行数据迁移操作，推荐生产环境下的做法为关闭镜像，开启 appendonly.aof，同时可以选择在访问较少的时间每天对 appendonly.aof 进行重写一次。

另外，对 master 机器, 主要负责写，建议使用 AOF, 对于 slave, 主要负责读，挑选出 1-2 台开启 AOF，其余的建议关闭

30 # appendfilename appendonly.aof

aof 文件名字，默认为 appendonly.aof

31 

# appendfsync always
appendfsync everysec
# appendfsync no

设置对 appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步，everysec 表示对写操作进行累积，每秒同步一次。no 不主动 fsync，由 OS 自己来完成。这个需要根据实际业务场景进行配置

32 no-appendfsync-on-rewrite no

在 aof rewrite 期间, 是否对 aof 新记录的 append 暂缓使用文件同步策略, 主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no, 表示 "不暂缓", 新的 aof 记录仍然会被立即同步

33 auto-aof-rewrite-percentage 100

当 Aof log 增长超过指定比例时，重写 log file， 设置为 0 表示不自动重写 Aof 日志，重写是为了使 aof 体积保持最小，而确保保存最完整的数据。

34 auto-aof-rewrite-min-size 64mb

触发 aof rewrite 的最小文件尺寸

35 lua-time-limit 5000

lua 脚本运行的最大时间

36 slowlog-log-slower-than 10000

"慢操作日志" 记录, 单位: 微秒 (百万分之一秒,1000 * 1000), 如果操作时间超过此值, 将会把 command 信息 "记录" 起来.(内存, 非文件)。其中 "操作时间" 不包括网络 IO 开支, 只包括请求达到 server 后进行 "内存实施" 的时间."0" 表示记录全部操作

37 slowlog-max-len 128

"慢操作日志" 保留的最大条数,"记录" 将会被队列化, 如果超过了此长度, 旧记录将会被移除。可以通过 "SLOWLOG <subcommand> args" 查看慢记录的信息 (SLOWLOG get 10,SLOWLOG reset)

38

 hash-max-ziplist-entries 512

hash 类型的数据结构在编码上可以使用 ziplist 和 hashtable。ziplist 的特点就是文件存储 (以及内存存储) 所需的空间较小, 在内容较小时, 性能和 hashtable 几乎一样. 因此 redis 对 hash 类型默认采取 ziplist。如果 hash 中条目的条目个数或者 value 长度达到阀值, 将会被重构为 hashtable。

这个参数指的是 ziplist 中允许存储的最大条目个数，，默认为 512，建议为 128
hash-max-ziplist-value 64

ziplist 中允许条目 value 值最大字节数，默认为 64，建议为 1024

39 

list-max-ziplist-entries 512
list-max-ziplist-value 64

对于 list 类型, 将会采取 ziplist,linkedlist 两种编码类型。解释同上。

40 set-max-intset-entries 512

intset 中允许保存的最大条目个数, 如果达到阀值,intset 将会被重构为 hashtable

41 

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

zset 为有序集合, 有 2 中编码类型:ziplist,skiplist。因为 "排序" 将会消耗额外的性能, 当 zset 中数据较多时, 将会被重构为 skiplist。

42 activerehashing yes

是否开启顶层数据结构的 rehash 功能, 如果内存允许, 请开启。rehash 能够很大程度上提高 K-V 存取的效率

43 

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

客户端 buffer 控制。在客户端与 server 进行的交互中, 每个连接都会与一个 buffer 关联, 此 buffer 用来队列化等待被 client 接受的响应信息。如果 client 不能及时的消费响应信息, 那么 buffer 将会被不断积压而给 server 带来内存压力. 如果 buffer 中积压的数据达到阀值, 将会导致连接被关闭,buffer 被移除。

buffer 控制类型包括:normal -> 普通连接；slave -> 与 slave 之间的连接；pubsub ->pub/sub 类型连接，此类型的连接，往往会产生此种问题; 因为 pub 端会密集的发布消息, 但是 sub 端可能消费不足.
指令格式:client-output-buffer-limit <class> <hard> <soft> <seconds>", 其中 hard 表示 buffer 最大值, 一旦达到阀值将立即关闭连接;
soft 表示 "容忍值", 它和 seconds 配合, 如果 buffer 值超过 soft 且持续时间达到了 seconds, 也将立即关闭连接, 如果超过了 soft 但是在 seconds 之后，buffer 数据小于了 soft, 连接将会被保留.
其中 hard 和 soft 都设置为 0, 则表示禁用 buffer 控制. 通常 hard 值大于 soft.

44 hz 10

Redis server 执行后台任务的频率, 默认为 10, 此值越大表示 redis 对 "间歇性 task" 的执行次数越频繁 (次数 / 秒)。"间歇性 task" 包括 "过期集合" 检测、关闭 "空闲超时" 的连接等, 此值必须大于 0 且小于 500。此值过小就意味着更多的 cpu 周期消耗, 后台 task 被轮询的次数更频繁。此值过大意味着 "内存敏感" 性较差。建议采用默认值。

45 

# include /path/to/local.conf
# include /path/to/other.conf

额外载入配置文件。

 

 

 

上面是 redis 配置文件里默认的 RDB 持久化设置，前三行都是对触发 RDB 的一个条件，例如第一行的意思是每 900 秒钟里 redis 数据库有一条数据被修改则触发 RDB，依次类推；只要有一条满足就会调用 BGSAVE 进行 RDB 持久化。第四行 dbfilename 指定了把内存里的数据库写入本地文件的名称，该文件是进行压缩后的二进制文件，通过该文件可以把数据库还原到生成该文件时数据库的状态。第五行 dir 指定了 RDB 文件存放的目录。

      配置文件修改需要重启 redis 服务，我们还可以在命令行里进行配置，即时生效，服务器重启后需重新配置

 

      而 RDB 持久化也分两种：SAVE 和 BGSAVE

      SAVE 是阻塞式的 RDB 持久化，当执行这个命令时 redis 的主进程把内存里的数据库状态写入到 RDB 文件（即上面的 dump.rdb）中，直到该文件创建完毕的这段时间内 redis 将不能处理任何命令请求。

      BGSAVE 属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入 RDB 文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的 redis 进程在系统上运行，会造成内存使用率的大幅增加。

（本人在生产中就碰到过这问题，redis 本身内存使用率就 60%，总的内存使用率在百分之七八十左右，持久化的时候立马飙到百分之一百三十多，告警邮件是每天几十封 /(ㄒ o ㄒ)/~~ 最后根据需求选择了 AOF 持久化）

 

       二、持久化之增量写入：AOF

       与 RDB 的保存整个 redis 数据库状态不同，AOF 是通过保存对 redis 服务端的写命令（如 set、sadd、rpush）来记录数据库状态的，即保存你对 redis 数据库的写操作，以下就是 AOF 文件的内容

 

       先让我们看看如何配置 AOF

      要弄明白上面几个配置就得从 AOF 的实现去理解，AOF 的持久化是通过命令追加、文件写入和文件同步三个步骤实现的。当 reids 开启 AOF 后，服务端每执行一次写操作（如 set、sadd、rpush）就会把该条命令追加到一个单独的 AOF 缓冲区的末尾，这就是命令追加；然后把 AOF 缓冲区的内容写入 AOF 文件里。看上去第二步就已经完成 AOF 持久化了那第三步是干什么的呢？这就需要从系统的文件写入机制说起：一般我们现在所使用的操作系统，为了提高文件的写入效率，都会有一个写入策略，即当你往硬盘写入数据时，操作系统不是实时的将数据写入硬盘，而是先把数据暂时的保存在一个内存缓冲区里，等到这个内存缓冲区的空间被填满或者是超过了设定的时限后才会真正的把缓冲区内的数据写入硬盘中。也就是说当 redis 进行到第二步文件写入的时候，从用户的角度看是已经把 AOF 缓冲区里的数据写入到 AOF 文件了，但对系统而言只不过是把 AOF 缓冲区的内容放到了另一个内存缓冲区里而已，之后 redis 还需要进行文件同步把该内存缓冲区里的数据真正写入硬盘上才算是完成了一次持久化。而何时进行文件同步则是根据配置的 appendfsync 来进行：

      appendfsync 有三个选项：always、everysec 和 no：

1、选择 always 的时候服务器会在每执行一个事件就把 AOF 缓冲区的内容强制性的写入硬盘上的 AOF 文件里，可以看成你每执行一个 redis 写入命令就往 AOF 文件里记录这条命令，这保证了数据持久化的完整性，但效率是最慢的，却也是最安全的；

2、配置成 everysec 的话服务端每执行一次写操作（如 set、sadd、rpush）也会把该条命令追加到一个单独的 AOF 缓冲区的末尾，并将 AOF 缓冲区写入 AOF 文件，然后每隔一秒才会进行一次文件同步把内存缓冲区里的 AOF 缓存数据真正写入 AOF 文件里，这个模式兼顾了效率的同时也保证了数据的完整性，即使在服务器宕机也只会丢失一秒内对 redis 数据库做的修改；

3、将 appendfsync 配置成 no 则意味 redis 数据库里的数据就算丢失你也可以接受，它也会把每条写命令追加到 AOF 缓冲区的末尾，然后写入文件，但什么时候进行文件同步真正把数据写入 AOF 文件里则由系统自身决定，即当内存缓冲区的空间被填满或者是超过了设定的时限后系统自动同步。这种模式下效率是最快的，但对数据来说也是最不安全的，如果 redis 里的数据都是从后台数据库如 mysql 中取出来的，属于随时可以找回或者不重要的数据，那么可以考虑设置成这种模式。

     

      相比 RDB 每次持久化都会内存翻倍，AOF 持久化除了在第一次启用时会新开一个子进程创建 AOF 文件会大幅度消耗内存外，之后的每次持久化对内存使用都很小。但 AOF 也有一个不可忽视的问题：AOF 文件过大。你对 redis 数据库的每一次写操作都会让 AOF 文件里增加一条数据，久而久之这个文件会形成一个庞然大物。还好的是 redis 提出了 AOF 重写的机制，即我们上面配置的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size。AOF 重写机制这里暂不细述，之后本人会另开博文对此解释，有兴趣的同学可以看看。我们只要知道 AOF 重写既是重新创建一个精简化的 AOF 文件，里面去掉了多余的冗余命令，并对原 AOF 文件进行覆盖。这保证了 AOF 文件大小处于让人可以接受的地步。而上面的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 配置触发 AOF 重写的条件。       

      Redis 会记录上次重写后 AOF 文件的文件大小，而当前 AOF 文件大小跟上次重写后 AOF 文件大小的百分比超过 auto-aof-rewrite-percentage 设置的值，同时当前 AOF 文件大小也超过 auto-aof-rewrite-min-size 设置的最小值，则会触发 AOF 文件重写。以上面的配置为例，当现在的 AOF 文件大于 64mb 同时也大于上次重写 AOF 后的文件大小，则该文件就会被 AOF 重写。

 

      最后需要注意的是，如果 redis 开启了 AOF 持久化功能，那么当 redis 服务重启时会优先使用 AOF 文件来还原数据库。

 

5、zookeeper 基本操作和了解
6、通过 Java 命令看进程，看 Java 进程的堆栈信息

jps(Java Virtual Machine Process Status Tool)

是 java 提供的一个显示当前所有 java 进程 pid 的命令，适合在 linux/unix 平台上简单察看当前 java 进程的一些简单情况。

很多人都是用过 unix 系统里的 ps 命令，这个命令主要是用来显示当前系统的进程情况，有哪些进程以及进程 id。 

jps 也是一样，它的作用是显示当前系统的 java 进程情况及进程 id。

我们可以通过它来查看我们到底启动了几个 java 进程（因为每一个 java 程序都会独占一个 java 虚拟机实例）

并可通过 opt 来查看这些进程的详细启动参数。

1. 使用方法：

注：在当前命令行下打 jps(jps 存放在 JAVA_HOME/bin/jps，使用时为了方便需将 JAVA_HOME/bin/ 加入到 Path) 。

$> jps

23991 Jps

23651 Resin

2. 常用参数：

-q 只显示 pid，不显示 class 名称,jar 文件名和传递给 main 方法的参数

$>  jps -q

28680

23789

-m 输出传递给 main 方法的参数，在嵌入式 jvm 上可能是 null

$> jps -m

28715 Jps -m

23789 BossMain

-l 输出应用程序 main class 的完整 package 名或者应用程序的 jar 文件完整路径名

$> jps -l

28729 sun.tools.jps.Jps

23789 com.asiainfo.aimc.bossbi.BossMain

23651

23651 Resin -socketwait 32768 -stdout /resin/log/stdout.log -stderr /resin/log/stderr.log

23651 com.caucho.server.resin.Resin

-v 输出传递给 JVM 的参数

$> jps -v

-V 隐藏输出传递给 JVM 的参数

$> jps -V

 jps 是 jdk 提供的一个查看当前 java 进程的小工具， 可以看做是 JavaVirtual Machine Process Status Tool 的缩写。非常简单实用。

       命令格式：jps [options] [hostid] 

       [options] 选项 ：
-q：仅输出 VM 标识符，不包括 classname,jar name,arguments in main method 
-m：输出 main method 的参数 
-l：输出完全的包名，应用主类名，jar 的完全路径名 
-v：输出 jvm 参数 
-V：输出通过 flag 文件传递到 JVM 中的参数 (.hotspotrc 文件或 -XX:Flags= 所指定的文件 
-Joption：传递参数到 vm, 例如:-J-Xms512m

        [hostid]：

[protocol:][[//]hostname][:port][/servername]

        命令的输出格式 ：
lvmid [[ classname| JARfilename | "Unknown"] [arg*] [jvmarg*] ]

1）jps

 

 

2）jps –l: 输出主类或者 jar 的完全路径名

 

3）jps –v : 输出 jvm 参数

 

4）jps –q ：仅仅显示 java 进程号

 

 

5)jps -mlv10.134.68.173

 

 

   jps -lvm 这个命令可以显示出程序，对应的进程号等，有关参数这里不讲述，如下：

查看对应程序的堆栈信息，就是找到进程号，执行 jstack 命令

   jstack -l 5659  这样就可以看堆栈信息了，这个是实时刷的，可以 写入一个文件中进行查看：  jstack -l 5659  > 1.txt

7、mysql，mysqldump 命令的操作，mysql 基本操作命令

 

 

mysqldump -h127.0.0.1 -P3306 -uroot -p123456 crm2 > backfile1.sql

 

 

8、怎样通过命令查看网络情况和 io 使用情况

 

 

备份 / 恢复案例

 

 

 

 

 

9、查找指定文件，查看某个文件大小和权限