Redis全量复制与部分复制示例详解

Redis 主从复制

  • Redis 实例划分为主节点(master)和从节点(slave)
  • 默认情况下，Redis都是主节点
  • 每个从节点只能有一个主节点，而主节点可以同时具有多个从节点
  • 复制的数据流是单向的，只能由主节点复制到从节点
  • slaveof 命令在使用时，可以运行期动态配置，也可以提前写到配置文件中
  • 主从复制
步骤 详细描述
保存主节点信息 执行slaveof后从节点只保存主节点的地址信息便直接返回
主从建立socket连接 从节点(slave)内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接;从节点会建立一个socket套接字，专门用于接受住节点发送的复制命令；如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveof no one 取消复制
发送ping命令 连接建立成功后从节点发送ping请求进行首次通信，ping请求的目的：检测主从之间套接字是否可用；检测主节点当前是否可接受处理命令.如果发送ping命令后，从节点没有收到主节点的pong回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会端口复制连接，下次定时任务会发起重连
权限验证 如果主节点设置了requirepass 参数，则需要密码验证，从节点必须配置masterauth参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程
同步数据集 主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点.
命令持续复制 当主节点把当前的数据同步给从节点后，变成了复制的建立流程，接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性
  • 启动6380、6381
  • 6381 执行命令
127.0.0.1:6381> slaveof 127.0.0.1 6380

Redis5.0.0 改为 ： replicaof <masterip> <masterport>
  • 6380 启动

6381 启动

查看info replication

数据同步

类型 描述
全量复制 一般用于初次复制场景，Redis早期支持的复制功能只有全量复制，它会把主节点全部数据一次性发送给从节点，当数据量较大时，会对主从节点和网络造成很大的开销
部分复制 用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销

复制偏移量

参数 描述
master_repl_offset 参与复制的主从节点都会维护自身复制偏移量。主节点(master)在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在info replication中的master_repl_offset指标中
slave0 从节点(slave) 每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量
slave_repl_offset 从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。

复制积压缓冲区

  • 复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为1MB，当主节点有连接的从节点(slave)时被创建，这是主节点(master)响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区
  • 由于缓冲区本质上是先进先出的定长队列，所以能实现保存最近已复制数据的功能，用于部分复制和复制命令丢失的数据补救
参数 描述
repl_backlog_active:1 开启复制缓冲区
repl_backlog_size:1048576 缓冲区最大长度
repl_backlog_first_byte_offset:1 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:2301 已保存数据的有效长度
master_replid 主节点实例的master_replid相同
master_replid2 未发生切换，即主实例未发生过变化，所以初始值为0

psync 命令

从节点使用psync命令完成部分复制和全量复制功能

30227:M 05 Aug 2019 18:52:44.698 * Replica 127.0.0.1:6381 asks for synchronization
30227:M 05 Aug 2019 18:52:44.698 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'e7d71fb600183a175afadbd1354e97edddb2541a', my replication IDs are 'e24f6e42917e7c162ec45a713b0ee3872005ee8b' and '0000000000000000000000000000000000000000')

6381 从节点打印分析

31771:S 06 Aug 2019 12:21:40.213 * DB loaded from disk: 0.000 seconds
31771:S 06 Aug 2019 12:21:40.213 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
#启动成功
31771:S 06 Aug 2019 12:21:40.213 * Ready to accept connections
# 开始连接主节点
31771:S 06 Aug 2019 12:21:40.214 * Connecting to MASTER 127.0.0.1:6380
# 开始同步
31771:S 06 Aug 2019 12:21:40.214 * MASTER <-> REPLICA sync started
31771:S 06 Aug 2019 12:21:40.214 * Non blocking connect for SYNC fired the event.
31771:S 06 Aug 2019 12:21:40.214 * Master replied to PING, replication can continue...
# 尝试增量同步
31771:S 06 Aug 2019 12:21:40.214 * Trying a partial resynchronization (request 668b25f85e84c5900e1032e4b5e1f038f01cfa49:5895).
# 全量同步
31771:S 06 Aug 2019 12:21:40.215 * Full resync from master: c88cd043d66193e867929d9d5fadc952954371e5:0
31771:S 06 Aug 2019 12:21:40.215 * Discarding previously cached master state.
31771:S 06 Aug 2019 12:21:40.240 * MASTER <-> REPLICA sync: receiving 224 bytes from master
31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Flushing old data
31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Loading DB in memory
31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Finished with success

全量复制

  • 全量复制是Redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。触发全量复制的命令是sync和psync

    • 发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所以发送psync-1
    • 主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应
    • 从节点接收主节点的响应数据保存运行ID和偏移量offset
    • 主节点执行bgsave保存RDB文件到本地
31651:M 06 Aug 2019 11:08:40.802 * Starting BGSAVE for SYNC with target: disk
31651:M 06 Aug 2019 11:08:40.802 * Background saving started by pid 31676
31676:C 06 Aug 2019 11:08:40.805 * DB saved on disk
31676:C 06 Aug 2019 11:08:40.806 * RDB: 0 MB of memory used by copy-on-write
31651:M 06 Aug 2019 11:08:40.886 * Background saving terminated with success
31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
  • 主节点发送RDB给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件,接收完RDB后从节点打印相关日志
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: receiving 224 bytes from master
  • 对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送个从节点，保证主从之间数据一致性。
  • redis.conf 配置
client-output-buffer-limit replica 256mb 64mb 60
  • 如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。默认配置如上所示，如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接，造成全量同步失败
  • 对于主节点，当发送完所有的数据后就认为全量复制完成.
31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
  • 从节点接收完主节点传送来的全部数据后会清空自身旧数据
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Flushing old data
  • 从节点清空数据后开始加载RDB文件，对于较大的RDB文件，这一步操作依然比较耗时，可以通过计算日志之间的时间差来判断加载RDB的总耗时
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Loading DB in memory
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Finished with success
  • 从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能，它会立刻做bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用。
  • 全量复制耗时的原因：
    • 主节点bgsave时间
    • RDB文件网络传输时间
    • 从节点清空数据时间
    • 可能的AOF重写时间
  • 以下为Redis 3.0才会有
标识 含义
M 当前为主节点日志
S 当前为从节点日志
C 子进程日志

部分复制

  • 部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync {runId}{offset}命令实现。当从节点(slave)正在复制主节点(master)时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区内存咋这部分数据则直接发送给从节点，这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据.

    • 当主节点直接网络出现中断是，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接
31767:M 06 Aug 2019 14:13:26.096 # Connection with replica 127.0.0.1:6381 lost.
  • 主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在的复制积压缓冲区，依然可以保存最近一段时间的写命令数据，默认最大缓存1MB，可以通过into replication 查看
  • 当从节点网络恢复后，从节点会再次连上主节点
从节点打印：
31934:S 06 Aug 2019 14:20:54.745 * MASTER <-> REPLICA sync started
31934:S 06 Aug 2019 14:20:54.745 * Non blocking connect for SYNC fired the event.
31934:S 06 Aug 2019 14:20:54.745 * Master replied to PING, replication can continue...
31934:S 06 Aug 2019 14:20:54.745 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:9996).
31934:S 06 Aug 2019 14:20:54.746 * Successful partial resynchronization with master.
31934:S 06 Aug 2019 14:20:54.746 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.

主节点打印：
31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization
31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.
  • 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当做psync参数发送个主节点，要求进行部分复制操作.从节点对应日志：
31938:S 06 Aug 2019 14:21:49.065 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:10066).
  • 主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+COUTINUE响应，表示可以进行部分复制。从节点接到回复打印如下：
31938:S 06 Aug 2019 14:21:49.066 * Successful partial resynchronization with master.
31938:S 06 Aug 2019 14:21:49.066 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.
  • 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。发送的数据量可以在主节点的日志获取
31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization
31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.

心跳

  • 主从节点在建立复制后,它们之间维护着长连接并彼此发送心跳命令
  • 主从心跳判断机制：
    • 主从节点彼此都有心跳检测机制，各自模拟对方的客户端进行通信，主节点的连接状态为flags=M,从节点连接状态为flags=S
    • 主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态。可以通过repl-ping-replica-period 10 控制发送频率
    • 从节点在主线程中每隔一秒发送replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量。主节点根据replconf命令判断从节点超时时间，体现在info replication 统计中的lag信息中，lag表示从节点最后一次通信延迟的秒数，正常延迟应该在0到1之间。如果超过repl-timeout配置的值(默认60秒),则判定从节点下线并断开复制客户端连接。即使主节点判定从节点下线后，如果从节点重新恢复，心跳检测和继续执行.

异步复制

  • 主节点不但负责数据读写，还负责把写命令同步给从节点。写命令的发送过程是异步完成，也就是说主节点自身处理完写命令后直接返回给客户端，并不等待从节点复制完成。

读写分离

  • 对于读占比较高的场景，可以通过把一部分读流量分摊到从节点(slave)来减轻主节点(master)压力，同时需要注意永远只对主节点执行写操作
  • 建议大家在做读写分离之前，可以考虑使用Redis Cluster 等分布式解决方案

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对我们的支持。

赞 (0)

相关推荐

  • Redis两种持久化方案RDB和AOF详解

    本文主要针对Redis 有两种持久化方案RDB和AOF做了详细的分析,希望我们整理的内容能够帮助大家对这个两种方案有更加深入的理解. Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File).如果你想快速了解和使用RDB和AOF,可以直接跳到文章底部看总结.本章节通过配置文件,触发快照的方式,恢复数据的操作,命令操作演示,优缺点来学习 Redis 的重点知识持久化. RDB 详解 RDB 是 Redis 默认的持久化方案.在指定的时间

  • redis学习之RDB、AOF与复制时对过期键的处理教程

    redis学习之RDB、AOF与复制时对过期键的处理教程

    生成RDB文件 在执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时,程序会对数据库中的键进行检查,已过期的键不会被保存到新创建的RDB文件中. 举个例子,如果数据库中包含三个键k1.k2.k3,并且k2已经过期,那么当执行SAVE命令或者BGSAVE命令时,程序只会将k1和k3的数据保存到RDB文件中,而k2则会被忽略. 因此,数据库中包含过期键不会对生成新的RDB文件造成影响. 可参考rdb.c中函数rdbSave()函数源码: /* Iterate this DB writing

  • Redis主从复制详解

    Redis主从复制详解

    单机Redis存在的问题 无法故障转移 ,无法避免单点故障 磁盘空间的瓶颈 QPS瓶颈 Redis主从复制的作用 提供数据副本 扩展读性能 配置方法 通过命令 通过配置文件 演示 为方便演示,在一台服务器上搭建redis主从(生产上不会这样做),根据端口区分. 主库 6379 从库 6380 编辑配置文件 vi  redis-6379.conf #后台进程启动 daemonize yes #端口 port 6379 #日志文件名称 logfile "6379.log" #Redis工作

  • redis主从复制原理的深入讲解

    前言 Redis持久化保证了即使redis服务重启也不会丢失数据,因为redis服务重启后会将硬盘上持久化的数据恢复到内存中,但是当redis服务器的硬盘损坏了可能会导致数据丢失,如果通过redis的主从复制机制就可以避免这种单点故障. 本文主要针对redis主从复制的原理进行了讲解,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧 1.复制过程 2.数据间的同步 3.全量复制 4.部分复制 5.心跳 6.异步复制 1.复制过程 从节点执行 slaveof 命令. 从节点只是保存了

  • Redis主从复制问题和扩容问题的解决思路

    一.解决主从复制问题 当使用Redis作为存储引擎的时候,并且使用Redis读写分离,从机作为读的情况,从机宕机或者和主机断开连接都需要重新连接主机,重新连接主机都会触发全量的主从复制,这时候主机会生成内存快照,主机依然可以对外提供服务,但是作为读的从机,就无法提供对外服务了,如果数据量大,恢复的时间会相当的长.为了解决Redis主从Copy的问题,有如下两个解决方案: 主动复制所谓主动复制,就是业务层双写多个Redis,避开Redis自带的主从复制.但是自己干同步,就会产生一致性问题,为了保证

  • Redis教程(九)：主从复制配置实例

    一.Redis的Replication: 这里首先需要说明的是,在Redis中配置Master-Slave模式真是太简单了.相信在阅读完这篇Blog之后你也可以轻松做到.这里我们还是先列出一些理论性的知识,后面给出实际操作的案例. 下面的列表清楚的解释了Redis Replication的特点和优势. 1). 同一个Master可以同步多个Slaves.     2). Slave同样可以接受其它Slaves的连接和同步请求,这样可以有效的分载Master的同步压力.因此我们可以将Redis的R

  • CentoS6.5环境下redis4.0.1(stable)安装和主从复制配置方法

    本文实例讲述了CentoS6.5环境下redis4.0.1(stable)安装和主从复制配置方法.分享给大家供大家参考,具体如下: 依赖环境 Centos 6.5 gcc-4.4.7:编译redis原文件 tcl-8.5.7:运行编译检测 1.编译redis #cd /usr/local #tar -zxvf redis-4.0.1.tar.gz #mv redis-4.0.1 redis #cd redis #make 运行编译测试make test需要tcl-8.5及以上 #yum inst

  • Redis源码设计剖析之事件处理示例详解

    Redis源码设计剖析之事件处理示例详解

    目录 1. Redis事件介绍 2. 事件的抽象 2.1 文件事件结构 2.2 时间事件结构 2.3 事件状态结构 3. 事件的实现 1. Redis事件介绍 Redis服务器是一个事件驱动程序,所谓事件驱动就是输入一条命令并且按下回车,然后消息被组装成Redis协议的格式发送给Redis服务器,这个时候就会产生一个事件,Redis服务器会接收改命令,处理该命令和发送回复,而当我们没有与服务器进行交互时,服务器就会处于阻塞等待状态,它会让出CPU然后进入睡眠状态,当事件触发时,就会被操作系统唤醒

  • redis实现加锁的几种方法示例详解

    前言 本文主要给大家介绍了关于redis实现加锁的几种方法,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 1. redis加锁分类 redis能用的的加锁命令分表是INCR.SETNX.SET 2. 第一种锁命令INCR 这种加锁的思路是, key 不存在,那么 key 的值会先被初始化为 0 ,然后再执行 INCR 操作进行加一. 然后其它用户在执行 INCR 操作进行加一时,如果返回的数大于 1 ,说明这个锁正在被使用当中. 1. 客户端A请求服务器获取key的值为1表示

  • Python实现强制复制粘贴的示例详解

    目录 前因后果 流程思路 代码展示 效果展示 前因后果 公司有人阳了,今天在家上班,突然小姨子就问我有没有baidu文库会员,想下载点东西,我心想这还要会员?用Python不是分分钟的事情! 然后我非常自信的告诉她不用会员随便下载,结果她顺势想来我家,还问我她姐姐在不在家,趁我一个人在家过来想干嘛?本着男孩子一个人在家要好好保护自己的原则,于是我过段拒绝了她! 兄弟们我做的对吗? 咱们来开始今天的内容,咱们不仅要强制复制粘贴,还要自动保存到world文档,就问你刑不刑! 需要的模块 reques

  • Redis全量同步和增量同步原理

    目录 全量同步 增量同步 总结 全量同步 主从第一次同步是全量同步:也就是说,当你主从节点连接建立后,需要执行一次全量同步.那么Redis如何实现全量同步呢? 其实本质就是Master 给 slave 发送其保存的RDB文件.slave读取RDB文件恢复数据 详细介绍: [第一步]slave与master建立连接后,master判断该slave 是否是第一次建立连接.那么该如何判断呢? 其实Master和slave都有一个Replication Id,简称replid,若id一致说明是已经建立过

  • MySQL六种约束的示例详解(全网最全)

    MySQL六种约束的示例详解(全网最全)

    目录 一.概述 二.约束演示 三.外键约束 1. 什么是外键约束 2. 不使用外键有什么影响 3. 添加外键的语法 4. 删除/更新行为 5. 演示删除/更新行为 四.主键id到底用自增好还是uuid好 五.实际开发尽量少用外键 一.概述 概念: 约束是作用于表中字段上的规则,用于限制存储在表中的数据. 目的: 保证数据库中数据的正确.有效性和完整性. 分类: 注意:约束是作用于表中字段上的,可以在创建表/修改表的时候添加约束. 二.约束演示 上面我们介绍了数据库中常见的约束,以及约束涉及到的关

  • redis分布式ID解决方案示例详解

    目录 常用的分布式ID解决方案 UUID Snowflake Snowflake算法的Java代码: Leaf Leaf算法的Java代码: 基于数据库自增ID生成 基于UUID生成 基于Redis生成 基于ZooKeeper生成 常用的分布式ID解决方案 在分布式系统中,生成全局唯一ID是非常重要的,因为在分布式系统中,多个节点同时生成ID可能会导致ID冲突. 下面介绍几种常用的分布式ID解决方案. UUID UUID(通用唯一标识符)是由128位数字组成的标识符,它可以保证在全球范围内的唯一

  • Golang分布式应用之Redis示例详解

    目录 正文 分布式锁 运行测试 分布式过滤器 运行测试 分布式限流器 运行测试 其他 正文 Redis作是一个高性能的内存数据库,常被应用于分布式系统中,除了作为分布式缓存或简单的内存数据库还有一些特殊的应用场景,本文结合Golang来编写对应的中间件. 本文所有代码见github.com/qingwave/go… 分布式锁 单机系统中我们可以使用sync.Mutex来保护临界资源,在分布式系统中同样有这样的需求,当多个主机抢占同一个资源,需要加对应的“分布式锁”. 在Redis中我们可以通过s

  • go实现Redis读写分离示例详解

    go实现Redis读写分离示例详解

    目录 我们为什么需要了解RESP协议? 什么是RESP协议 RESP协议规范 如何使用该协议请求Redis 使用go编写Redis中间件实现读写分离 总结 我们为什么需要了解RESP协议? 本篇文章目的为探究RESP协议,而非编写读写中间件,这点要清楚. 关于这个问题,我想通过一个实例来解释,我们编写Redis中间件,为什么需要了解RESP协议. 以上代码是编写了一个非常简单的TCP服务器,我们监听8888端口,尝试使用redis-cli -p 8888连接服务器后,而后查看打印出来的应用层报文

  • Java垃圾回收机制的示例详解

    Java垃圾回收机制的示例详解

    目录 一.概述 二.对象已死? 1.引用计数算法 2.可达性分析算法 3.四种引用 4.生存还是死亡? 5.回收方法区 三.垃圾收集算法 1.分代收集理论 2.名词解释 3.标记-清除算法 4.标记-复制算法 5.标记-整理算法 一.概述 说起垃圾收集(Garbage Collection,下文简称GC),有不少人把这项技术当作Java语言的伴生产 物.事实上,垃圾收集的历史远远比Java久远,在1960年诞生于麻省理工学院的Lisp是第一门开始使 用内存动态分配和垃圾收集技术的语言.当Lisp

  • Go gRPC环境安装教程示例详解

    Go gRPC环境安装教程示例详解

    目录 前言 安装 protobuf 安装相关包 创建并编译proto文件 VSCode-proto3插件介绍 前言 gRPC 是一个高性能.开源和通用的 RPC 框架,面向移动和 HTTP/2 设计,带来诸如双向流.流控.头部压缩.单 TCP 连接上的多复用请求等特.这些特性使得其在移动设备上表现更好,更省电和节省空间占用. 在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法,使得您能够更容易地创建分布式应用和服务. gRPC 默认使用 protocol

随机推荐