Redis配置文件

Redis配置文件

redis 主要配置项:
bind 0.0.0.0            #监听地址,可以用空格隔开后多个监听 IP
protected-mode yes      #redis3.2 之后加入的新特性,在没有设置 bind IP 和密码的时候只允许访问127.0.0.1:6379
port 6379               #监听端口
tcp-backlog 511         #三次握手的时候 server 端收到 client ack 确认号之后的队列值。
timeout 0               #客户端和 Redis 服务端的连接超时时间,默认是 0,表示永不超时。
tcp-keepalive 300       #tcp 会话保持时间
daemonize no            #默认情况下 redis 不是作为守护进程运行的,如果你想让它在后台运行,你就把它改成yes,当 redis 作为守护进程运行的时候,它会写一个 pid 到 /var/run/redis.pid 文件里面
supervised no           #和操作系统相关参数,可以设置通过 upstart 和 systemd 管理 Redis 守护进程,centos 7以后都使用 systemd
pidfile /var/run/redis_6379.pid     #pid 文件路径
loglevel notice         #日志级别

logfile ""              #日志路径
databases 16            #设置 db 库数量,默认 16 个库
always-show-logo yes    #在启动 redis 时是否显示 log

save 900 1              #在 900 秒内有一个键内容发生更改就出就快照机制
save 300 10
save 60 10000
stop-writes-on-bgsave-error no     #快照出错时是否禁止 redis 写入操作
rdbcompression yes      #持久化到 RDB 文件时,是否压缩,"yes"为压缩,"no"则反之
rdbchecksum yes         #是否开启 RC64 校验,默认是开启
dbfilename dump.rdb     #快照文件名
dir ./                  #快照文件保存路径

replica-serve-stale-data yes    #当从库同主库失去连接或者复制正在进行,从机库有两种运行方式:1) 如果 replica-serve-stale-data 设置为 yes(默认设置),从库会继续响应客户端的读请求。2) 如果 replicaserve-stale-data 设置为 no,除去指定的命令之外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes           #是否设置从库只读
repl-diskless-sync no           #是否使用 socket 方式复制数据,目前 redis 复制提供两种方式,disk 和 socket,如果新的 slave 连上来或者重连的 slave 无法部分同步,就会执行全量同步,master 会生成 rdb 文件,有 2 种方式:disk 方式是 master 创建一个新的进程把 rdb 文件保存到磁盘,再把磁盘上的 rdb 文件传递给 slave,socket 是 master 创建一个新的进程,直接把 rdb 文件以 socket 的方式发给 slave,disk 方式的时候,当一个 rdb 保存的过程中,多个 slave 都能共享这个 rdb 文件,socket 的方式就是一个个 slave顺序复制,只有在磁盘速度缓慢但是网络相对较快的情况下才使用 socket 方式,否则使用默认的 disk方式
repl-diskless-sync-delay 30     #diskless 复制的延迟时间,设置 0 为关闭,一旦复制开始还没有结束之前,master 节点不会再接收新 slave 的复制请求,直到下一次开始
repl-ping-slave-period 10       #slave 根据 master 指定的时间进行周期性的 PING 监测
repl-timeout 60         #复制链接超时时间,需要大于 repl-ping-slave-period,否则会经常报超时
repl-disable-tcp-nodelay no     #在 socket 模式下是否在 slave 套接字发送 SYNC 之后禁用 TCP_NODELAY,如果你选择“yes”Redis 将使用更少的 TCP 包和带宽来向 slaves 发送数据。但是这将使数据传输到 slave上有延迟,Linux 内核的默认配置会达到 40 毫秒,如果你选择了 "no" 数据传输到 salve 的延迟将会减少但要使用更多的带宽
repl-backlog-size 1mb           #复制缓冲区大小,只有在 slave 连接之后才分配内存。
repl-backlog-ttl 3600           #多次时间 master 没有 slave 连接,就清空 backlog 缓冲区。
replica-priority 100            #当 master 不可用,Sentinel 会根据 slave 的优先级选举一个 master。最低的优先级的 slave,当选 master。而配置成 0,永远不会被选举。
requirepass foobared            #设置 redis 连接密码
rename-command                  #重命名一些高危命令
maxclients 10000                #最大连接客户端
maxmemory                       #最大内存,单位为 bytes 字节,8G 内存的计算方式 8(G)*1024(MB)*1024(KB)*1024(Kbyte),需要注意的是 slave 的输出缓冲区是不计算在 maxmemory 内。

appendonly no                   #是否开启 AOF 日志记录,默认 redis 使用的是 rdb 方式持久化,这种方式在许多应用中已经足够用了。但是 redis 如果中途宕机,会导致可能有几分钟的数据丢失,根据 save 来策略进行持久化,Append Only File 是另一种持久化方式,可以提供更好的持久化特性。Redis 会把每次写入的数据在接收后都写入 appendonly.aof 文件,每次启动时 Redis 都会先把这个文件的数据读入内存里,先忽略 RDB 文件。
appendfilename "appendonly.aof" #AOF 文件名
appendfsync everysec            #aof 持久化策略的配置,no 表示不执行 fsync,由操作系统保证数据同步到磁盘,always 表示每次写入都执行 fsync,以保证数据同步到磁盘,everysec 表示每秒执行一次 fsync,可能会导致丢失这 1s 数据。no-appendfsync-on-rewrite no 在 aof rewrite 期间,是否对 aof 新记录的 append 暂缓使用文件同步策略,主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no,表示"不暂缓",新的 aof 记录仍然会被立即同步,Linux 的默认 fsync 策略是 30 秒,如果为 yes 可能丢失 30 秒数据,但由于 yes 性能较好而且会避免出现阻塞因此比较推荐。
auto-aof-rewrite-percentage 100 # 当 Aof log 增长超过指定百分比例时,重写 log file, 设置为 0 表示不自动重写 Aof 日志,重写是为了使 aof 体积保持最小,而确保保存最完整的数据。
auto-aof-rewrite-min-size 64mb  #触发 aof rewrite 的最小文件大小

aof-load-truncated yes          #是否加载由于其他原因导致的末尾异常的 AOF 文件(主进程被 kill/断电等)
aof-use-rdb-preamble yes        #redis4.0 新增 RDB-AOF 混合持久化格式,在开启了这个功能之后,AOF 重写产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容,其中 RDB 格式的内容用于记录已有的数据,而 AOF 格式的内存则用于记录最近发生了变化的数据,这样 Redis 就可以同时兼有 RDB 持久化和AOF 持久化的优点(既能够快速地生成重写文件,也能够在出现问题时,快速地载入数据)。
lua-time-limit 5000             #lua 脚本的最大执行时间,单位为毫秒

cluster-enabled yes             #是否开启集群模式,默认是单机模式
cluster-config-file nodes-6379.conf #由 node 节点自动生成的集群配置文件
cluster-node-timeout 15000      #集群中 node 节点连接超时时间
cluster-replica-validity-factor 10 #在执行故障转移的时候可能有些节点和 master 断开一段时间数据比较旧,这些节点就不适用于选举为 master,超过这个时间的就不会被进行故障转移

cluster-migration-barrier 1     #一个主节点拥有的至少正常工作的从节点,即如果主节点的 slave 节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。
cluster-require-full-coverage no #集群槽位覆盖,如果一个主库宕机且没有备库就会出现集群槽位不全,那么 yes 情况下 redis 集群槽位验证不全就不再对外提供服务,而 no 则可以继续使用但是会出现查询数据查不到的情况(因为有数据丢失)。

#Slow log 是 Redis 用来记录查询执行时间的日志系统,slow log 保存在内存里面,读写速度非常快,因此你可以放心地使用它,不必担心因为开启 slow log 而损害 Redis 的速度。
slowlog-log-slower-than 10000   #以微秒为单位的慢日志记录,为负数会禁用慢日志,为 0 会记录每个命令操作。

slowlog-max-len 128 #记录多少条慢日志保存在队列,超出后会删除最早的,以此滚动删除
127.0.0.1:6379> slowlog len
(integer) 14
127.0.0.1:6379> slowlog get
1) 1) (integer) 14
 2) (integer) 1544690617
 3) (integer) 4
 4) 1) "slowlog"
127.0.0.1:6379> SLOWLOG reset
OK
redis 持久化:
redis 虽然是一个内存级别的缓存程序,即 redis 是使用内存进行数据的缓存的,但是其可以将内存
的数据按照一定的策略保存到硬盘上,从而实现数据持久保存的目的,redis 支持两种不同方式的数据
持久化保存机制,分别是 RDB 和 AOF
RDB 模式:
RDB:基于时间的快照,只保留当前最新的一次快照,特点是执行速度比较快,缺点是可能会丢失从
上次快照到当前快照未完成之间的数据。
RDB 实现的具体过程 Redis 从主进程先 fork 出一个子进程,使用写时复制机制,子进程将内存的数据
保存为一个临时文件,比如 dump.rdb.temp,当数据保存完成之后再将上一次保存的 RDB 文件替换掉,
然后关闭子进程,这样可以保存每一次做 RDB 快照的时候保存的数据都是完整的,因为直接替换 RDB
文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关机停止保存而导致
数据丢失的情况,可以手动将每次生成的 RDB 文件进程备份,这样可以最大化保存历史数据。

在这里插入图片描述

RDB 模式的优缺点:
优点:
-RDB 快照保存了某个时间点的数据,可以通过脚本执行 bgsave(非阻塞)或者 save(阻塞)命令自定义时间点北备份,可以保留多个备份,当出现问题可以恢复到不同时间点的版本。
-可以最大化 o 的性能,因为父进程在保存 RDB 文件的时候唯一要做的是 fork 出一个子进程,然后的操作都会有这个子进程操作,父进程无需任何的 IO 操作RDB ,在大量数据比如几个 G 的数据,恢复的速度比 AOF 的快

缺点:
-不能时时的保存数据,会丢失自上一次执行 RDB 备份到当前的内存数据
-数据量非常大的时候,从父进程 fork 的时候需要一点时间,可能是毫秒或者秒
AOF 模式:
AOF:按照操作顺序依次将操作添加到指定的日志文件当中,特点是数据安全性相对较高,缺点是即使
有些操作是重复的也会全部记录。
AOF 和 RDB 一样使用了写时复制机制,AOF 默认为每秒钟 fsync 一次,即将执行的命令保存到 AOF 文
件当中,这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之内的数据,也可以设置不同的 fsync
策略,或者设置每次执行命令的时候执行 fsync,fsync 会在后台执行线程,所以主线程可以继续处理
用户的正常请求而不受到写入 AOF 文件的 IO 影响
AOF 模式优缺点:
AOF 的文件大小要大于 RDB 格式的文件
根据所使用的 fsync 策略(fsync 是同步内存中 redis 所有已经修改的文件到存储设备),默认是
appendfsync everysec 即每秒执行一次 fsync
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在现有省、市港口信息化系统进行有效整合基础上,借鉴新 一代的感知-传输-应用技术体系,实现对码头、船舶、货物、重 大危险源、危险货物装卸过程、航管航运等管理要素的全面感知、 有效传输和按需定制服务,为行政管理人员和相关单位及人员提 供高效的管理辅助,并为公众提供便捷、实时的水运信息服务。 建立信息整合、交换和共享机制,建立健全信息化管理支撑 体系,以及相关标准规范和安全保障体系;按照“绿色循环低碳” 交通的要求,搭建高效、弹性、高可扩展性的基于虚拟技术的信 息基础设施,支撑信息平台低成本运行,实现电子政务建设和服务模式的转变。 实现以感知港口、感知船舶、感知货物为手段,以港航智能 分析、科学决策、高效服务为目的和核心理念,构建“智慧港口”的发展体系。 结合“智慧港口”相关业务工作特点及信息化现状的实际情况,本项目具体建设目标为: 一张图(即GIS 地理信息服务平台) 在建设岸线、港口、港区、码头、泊位等港口主要基础资源图层上,建设GIS 地理信息服务平台,在此基础上依次接入和叠加规划建设、经营、安全、航管等相关业务应用专题数据,并叠 加动态数据,如 AIS/GPS/移动平台数据,逐步建成航运管理处 "一张图"。系统支持扩展框架,方便未来更多应用资源的逐步整合。 现场执法监管系统 基于港口(航管)执法基地建设规划,依托统一的执法区域 管理和数字化监控平台,通过加强对辖区内的监控,结合移动平 台,形成完整的多维路径和信息追踪,真正做到问题能发现、事态能控制、突发问题能解决。 运行监测和辅助决策系统 对区域港口与航运业务日常所需填报及监测的数据经过科 学归纳及分析,采用统一平台,消除重复的填报数据,进行企业 输入和自动录入,并进行系统智能判断,避免填入错误的数据, 输入的数据经过智能组合,自动生成各业务部门所需的数据报 表,包括字段、格式,都可以根据需要进行定制,同时满足扩展 性需要,当有新的业务监测数据表需要产生时,系统将分析新的 需求,将所需字段融合进入日常监测和决策辅助平台的统一平台中,并生成新的所需业务数据监测及决策表。 综合指挥调度系统 建设以港航应急指挥中心为枢纽,以各级管理部门和经营港 口企业为节点,快速调度、信息共享的通信网络,满足应急处置中所需要的信息采集、指挥调度和过程监控等通信保障任务。 设计思路 根据项目的建设目标和“智慧港口”信息化平台的总体框架、 设计思路、建设内容及保障措施,围绕业务协同、信息共享,充 分考虑各航运(港政)管理处内部管理的需求,平台采用“全面 整合、重点补充、突出共享、逐步完善”策略,加强重点区域或 运输通道交通基础设施、运载装备、运行环境的监测监控,完善 运行协调、应急处置通信手段,促进跨区域、跨部门信息共享和业务协同。 以“统筹协调、综合监管”为目标,以提供综合、动态、实 时、准确、实用的安全畅通和应急数据共享为核心,围绕“保畅通、抓安全、促应急"等实际需求来建设智慧港口信息化平台。 系统充分整合和利用航运管理处现有相关信息资源,以地理 信息技术、网络视频技术、互联网技术、移动通信技术、云计算 技术为支撑,结合航运管理处专网与行业数据交换平台,构建航 运管理处与各部门之间智慧、畅通、安全、高效、绿色低碳的智 慧港口信息化平台。 系统充分考虑航运管理处安全法规及安全职责今后的变化 与发展趋势,应用目前主流的、成熟的应用技术,内联外引,优势互补,使系统建设具备良好的开放性、扩展性、可维护性。
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值