- 总结tomcat优化方法
- 1.内存空间优化
- 2.内存空间优化
- 3.线程池调整
- java程序出现oom如何解决？什么场景下会出现oom？
- 1. 什么是oom?
- 2. 为什么会OOM？
- 简述redis特点及其应用场景
- 1.特点:
- 2.应用场景
- 2.1 缓存
- 2.2 排行榜系统
- 2.3 计数器应用
- 2.4 消息队列系统
- 2.5 社交网络
- 对比redis的RDB、AOF模式的优缺点
- 1、RDB模式
- 1.1 工作原理
- 1.2 RDB优点
- 1.3 RDB缺点
- 2、AOF模式
- 2.1 工作原理
- 2.2 AOF优点
- 2.3 AOF缺点
- 实现redis哨兵，模拟master故障场景
- 环境准备
- 1、实现主从复制架构
- 1.1 安装redis
- 1.2 修改配置文件
- 1.3 启动redis
- 1.4 查看主从复制状态
- 2、配置哨兵
- 2.1 实现哨兵
- 3、模拟master故障场景
- 3.1 模拟故障，停掉master
- 3.2 查看日志
- 3.3 故障恢复
配置文件目录:/usr/local/tomcat/bin/catalina.sh
JAVA_OPTS="-server -Xms4g -Xmx4g -XX:NewSize= -XX:MaxNewSize= " -server：服务器模式 -Xms：堆内存初始化大小 -Xmx：堆内存空间上限 -XX:NewSize=：新生代空间初始化大小 -XX:MaxNewSize=：新生代空间最大值2.内存空间优化
系统允许当前用户进程打开的文件数量的限制， 默认值为10243.线程池调整
#vim /usr/local/tomcat/conf/server.xml............
常用属性： connectionTimeout ：连接超时时长,单位ms maxThreads：最大线程数，默认200 minSpareThreads：最小空闲线程数 maxSpareThreads：最大空闲线程数 acceptCount：当启动线程满了之后，等待队列的最大长度，默认100 URIEncoding：URI 地址编码格式，建议使用 UTF-8 enableLookups：是否启用客户端主机名的DNS反向解析，缺省禁用，建议禁用，就使用客户端IP就行 compression：是否启用传输压缩机制，建议 "on"，CPU和流量的平衡 compressionMinSize：启用压缩传输的数据流最小值，单位是字节 compressableMimeType：定义启用压缩功能的MIME类型text/html, text/xml, text/css,text/javascriptjava程序出现oom如何解决？什么场景下会出现oom？ 1. 什么是oom?
OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。 当JVM因为没有足够的内存来为对象分配空间、并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。2. 为什么会OOM？
为什么会没有内存了呢？原因不外乎有两点： 1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。 2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。简述redis特点及其应用场景 1.特点:
速度快: 10W QPS,基于内存,C语言实现 单线程 持久化 支持多种数据结构 支持多种编程语言 功能丰富: 支持Lua脚本,发布订阅,事务,pipeline等功能 简单: 代码短小精悍(单机核心代码只有23000行左右),单线程开发容易,不依赖外部库,使用简单 主从复制 支持高可用和分布式2.应用场景 2.1 缓存
缓存可以说是Redis最常用的功能之一了，合理的缓存不仅可以加快速度的访问速度，以及可以减少后端的压力(通常就是MySQL的压力)。 可以说，一个合理的缓存可以极大地提高网站的性能。2.2 排行榜系统
利用Redis的列表和有序集合的特点，可以制作排行榜系统，而排行榜系统目前在商城类、新闻类、博客类等等，都是比不可缺的。2.3 计数器应用
计数器的应用基本和排行榜系统一样，都是多数网站的普遍需求，如视频网站的播放计数，电商网站的浏览数等等，但这些数量一般比较庞大，如果存到关系型数据库，对MySQL或者其他关系型数据库的挑战还是很大的，而Redis基本可以说是天然支持计数器应用。2.4 消息队列系统
Redis支持发布订阅系统和阻塞队列的功能，可以充当一般的消息队列功能，虽然和专业的消息队列MQ比如RebbitMQ比起来还优点差距，但也基本够用了，比如celery的异步模型，Redis也是celery官方指定的2种队列的一种。2.5 社交网络
对于社交网络来说，一般用户量是及其庞大的，此时的关系型数据库就捉襟见肘了，比如好有点赞、关注、推送等等功能，用Redis就能比较轻松地实现这些功能对比redis的RDB、AOF模式的优缺点 1、RDB模式 1.1 工作原理
RDB(Redis DataBase)：基于时间的快照，其默认只保留当前最新的一次快照，特点是执行速度比较快，缺点是可
能会丢失从上次快照到当前时间点之间未做快照的数据。
RDB bgsave 实现快照的具体过程：
Redis从master主进程先fork出一个子进程，使用写时复制机制，将内存的数据保存为一个临时文件，比如:tmp.rdb。当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程，这样可以保证每一次做RDB快照保存的数据都是完整的。
因为直接替换RDB文件的时候，可能会出现突然断电等问题，而导致RDB文件还没有保存完整就因为突然关机停止保存，而导致数据丢失的情况。后续可以手动将每次生成的RDB文件进行备份，这样可以最大化保存历史数据。
1.2 RDB优点RDB是基于时间的快照，即保存了某个时间点的数据。很适合备份,可以根据自身的业务需求灵活调整备份频率。并且此文件格式也支持有不少第三方工具可以进行后续的数据分析。即使遇上问题，也可以随时将数据集还原到不同的版本。
RDB可以最大化Redis的性能，父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘工/0操作。
RDB在大量数据,比如几个G的数据，恢复的速度比AOF的快
RDB本身的备份机制决定了不能实时保存数据，因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下，一旦发生故障停机，就可能会丢失好几分钟的数据。
当数据量非常大的时候，从父进程fork子进程进行保存至RDB文件时需要一点时间，可能是毫秒或者秒，取决于磁盘IO性能。在数据集比较庞大时，fork()可能会非常耗时，造成服务器在一定时间内停止处理客户端﹔如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。虽然 AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的持久性都不会有任何损失。
2、AOF模式 2.1 工作原理AOF：AppendOnylFile：按照操作顺序依次将操作追加到指定的日志文件末尾。
AOF和RDB一样使用了写时复制机制，AOF默认为每秒钟 fsync一次，即将执行的命令保存到AOF文件当中，这样即使redis服务器发生故障的话最多只丢失1秒钟之内的数据，也可以设置不同的fsync策略always，即设置每次执行命令的时候执行fsync，fsync会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入AOF文件的I/O影响。。
2.2 AOF优点数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存
储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保
持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，
所以主线程可以继续努力地处理命令请求)
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现
宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现
了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据
一致性的问题。
Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了
恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件
的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停
机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新
AOF文件，并开始对新AOF文件进行追加操作。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文
件完成数据的重建。
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因
此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件
也非常简单:举个例子，如果不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只要停
止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到FLUSHALL执
行之前的状态
即使有些操作是重复的也会全部记录，AOF 的文件大小要大于 RDB 格式的文件
AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
根据fsync策略不同,AOF速度可能会慢于RDB
bug 出现的可能性更多
由于主从架构无法实现master和slave角色的自动切换，所以在发送master节点宕机时，redis主从复制无法实现自动的故障转移，即将slave 自动提升为新的master。因此，需要配置哨兵来"盯"着它们干活，一旦发现master节点宕机，会快速的将slave节点提升为新master节点。
### #在所有节点都安装redis yum install redis -y1.2 修改配置文件
#所有节点都修改如下： [root@localhost ~]#vim /etc/redis.conf # replicaof1.3 启动redisreplicaof 10.0.0.8 6379 #指定master的IP和端口号 ....省略 # masterauth masterauth 123456 ...省略
# systemctl enable --now redis # ss -ntl ss -State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 511 0.0.0.0:6379 0.0.0.0:* ...省略...1.4 查看主从复制状态
#在master节点查看到如下内容: [root@localhost ~]#redis-cli -a 123456 info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:master connected_slaves:2 slave0:ip=10.0.0.18,port=6379,state=online,offset=6398,lag=0 slave1:ip=10.0.0.28,port=6379,state=online,offset=6398,lag=1 master_failover_state:no-failover master_replid:1d5939408b470ad048e8e397b2c258836c6caa73 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:6398 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:63982、配置哨兵 2.1 实现哨兵
Sentinel实际上是一个特殊的redis服务器,有些redis指令支持,但很多指令并不支持.默认监听在26379/tcp端口。
##每个节点配置相同
# cp /etc/redis-sentinel.conf{,.bak}
# cat > /etc/redis-sentinel.conf<
3、模拟master故障场景
3.1 模拟故障，停掉master
停掉身为master的主机10.0.0.8
# systemctl stop redis
3.2 查看日志
3.3 故障恢复
# systemctl start redis
可以发现，当master恢复重新加入回来后，并没有重新获得master，而是以slave身份存在
