发表于 2017-10-11 16:04:25
1.Redis Cluster总览
1.1 设计原则和初衷
在官方文档Cluster Spec中，作者详细介绍了Redis集群为什么要设计成现在的样子。最核心的目标有三个：
- 性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
- 水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到1000结点。
- 可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。
1.2 架构变化与CAP理论
Redis Cluster集群功能推出已经有一段时间了。在单机版的Redis中，每个Master之间是没有任何通信的，所以我们一般在Jedis客户端或者Codis这样的代理中做Pre-sharding。按照CAP理论来说，单机版的Redis属于保证CP(Consistency & Partition-Tolerancy)而牺牲A(Availability)，也就说Redis能够保证所有用户看到相同的数据（一致性，因为Redis不自动冗余数据）和网络通信出问题时，暂时隔离开的子系统能继续运行（分区容忍性，因为Master之间没有直接关系，不需要通信），但是不保证某些结点故障时，所有请求都能被响应（可用性，某个Master结点挂了的话，那么它上面分片的数据就无法访问了）。
有了Cluster功能后，Redis从一个单纯的NoSQL内存数据库变成了分布式NoSQL数据库，CAP模型也从CP变成了AP。也就是说，通过自动分片和冗余数据，Redis具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了Availability。然而，也正因为这一点，Redis无法保证曾经的强一致性了。这也是CAP理论要求的，三者只能取其二。
关于CAP理论的通俗讲解，请参考我的译文《可能是CAP理论的最好解释 》。简单分析了Redis在架构上的变化后，咱们就一起来体验一下Redis Cluster功能吧！
2.Redis集群初探
Redis的安装很简单，以前已经介绍过，就不详细说了。关于Redis Cluster的基础知识之前也有过整理，请参考《Redis集群功能预览》。如果需要全面的了解，那一定要看官方文档Cluster Tutorial，只看这一个就够了！
2.1 集群配置
要想开启Redis Cluster模式，有几项配置是必须的。此外为了方便使用和后续的测试，我还额外做了一些配置：
- 绑定地址：bind 192.168.XXX.XXX。不能绑定到127.0.0.1或localhost，否则指导客户端重定向时会报”Connection refused”的错误。
- 开启Cluster：cluster-enabled yes
- 集群配置文件：cluster-config-file nodes-7000.conf。这个配置文件不是要我们去配的，而是Redis运行时保存配置的文件，所以我们也不可以修改这个文件。
- 集群超时时间：cluster-node-timeout 15000。结点超时多久则认为它宕机了。
- 槽是否全覆盖：cluster-require-full-coverage no。默认是yes，只要有结点宕机导致16384个槽没全被覆盖，整个集群就全部停止服务，所以一定要改为no
- 后台运行：daemonize yes
- 输出日志：logfile “./redis.log”
- 监听端口：port 7000
配置好后，根据我们的集群规模，拷贝出来几份同样的配置文件，唯一不同的就是监听端口，可以依次改为7001、7002… 因为Redis Cluster如果数据冗余是1的话，至少要3个Master和3个Slave，所以我们拷贝出6个实例的配置文件。为了避免相互影响，为6个实例的配置文件建立独立的文件夹。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
2.2 redis-trib管理器
Redis作者应该是个Ruby爱好者，Ruby客户端就是他开发的。这次集群的管理功能没有嵌入到Redis代码中，于是作者又顺手写了个叫做redis-trib的管理脚本。redis-trib依赖Ruby和RubyGems，以及redis扩展。可以先用which命令查看是否已安装ruby和rubygems，用gem list –local查看本地是否已安装redis扩展。
最简便的方法就是用apt或yum包管理器安装RubyGems后执行gem install redis。如果网络或环境受限的话，可以手动安装RubyGems和redis扩展（国外链接可能无法下载，可以从CSDN下载）：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
2.3 集群建立
首先，启动我们配置好的6个Redis实例。
- 1
- 2
- 3
- 4
此时6个实例还没有形成集群，现在用redis-trb.rb管理脚本建立起集群。可以看到，redis-trib默认用前3个实例作为Master，后3个作为Slave。因为Redis基于Master-Slave做数据备份，而非像Cassandra或Hazelcast一样不区分结点角色，自动复制并分配Slot的位置到各个结点。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
至此，集群就已经建立成功了！“贴心”的Redis还在utils/create-cluster下提供了一个create-cluster脚本，能够创建出一个集群，类似我们上面建立起的3主3从的集群。
2.4 简单测试
我们连接到集群中的任意一个结点，启动redis-cli时要加-c选项，存取两个Key-Value感受一下Redis久违的集群功能。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
仔细观察能够注意到，redis-cli根据指示，不断在7000和7002结点之前重定向跳转。如果启动时不加-c选项的话，就能看到以错误形式显示出的MOVED重定向消息。
- 1
- 2
- 3
2.5 集群重启
目前redis-trib的功能还比较弱，需要重启集群的话先手动kill掉各个进程，然后重新启动就可以了。这也有点太… 网上有人重启后会碰到问题，我还比较幸运，这种“土鳖”的方式重启试了两次还没发现问题。
- 1
3.高级功能尝鲜
说是“高级功能”，其实在其他分布式系统中早就都有实现了，只不过在Redis世界里是比较新鲜的。本部分主要试验一下Redis Cluster中的数据迁移(Resharding)和故障转移功能。
3.1 数据迁移
本小节我们体验一下Redis集群的Resharding功能！
3.1.1 创建测试数据
首先保存foo1~10共10个Key-Value作为测试数据。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
3.1.2 启动新结点
参照之前的方法新拷贝出两份redis.conf配置文件redis.conf.7010和7011，与之前结点的配置文件做一下区分。启动新的两个Redis实例之后，通过redis-trib.rb脚本添加新的Master和Slave到集群中。
- 1
- 2
3.1.3 添加到集群
使用redis-trib.rb add-node分别将两个新结点添加到集群中，一个作为Master，一个作为其Slave。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
3.1.4 Resharding
通过redis-trib.rb reshard可以交互式地迁移Slot。下面的例子将5000个Slot从7000~7002迁移到7010上。也可以通过./redis-trib.rb reshard <host>:<port> --from <node-id> --to <node-id> --slots --yes在程序中自动完成迁移。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
迁移完成后，查看之前保存的foo1~10的分布情况，可以看到部分Key已经迁移到了新的结点7010上。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
3.2 故障转移
在高可用性方面，Redis可算是能够”Auto”一把了！Redis Cluster重用了Sentinel的代码逻辑，不需要单独启动一个Sentinel集群，Redis Cluster本身就能自动进行Master选举和Failover切换。
下面我们故意kill掉7010结点，之后可以看到结点状态变成了fail，而Slave 7011被选举为新的Master。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
尝试查询之前保存在7010上的Key，可以看到7011顶替上来继续提供服务，整个集群没有受到影响。
- 1
- 2
- 3
- 4
- 5
4.内部原理剖析
前面我们已经学习过，用Redis提供的redis-trib或create-cluster脚本能几步甚至一步就建立起一个Redis集群。这一部分我们为了深入学习，所以要暂时抛开这些方便的工具，完全手动建立一遍上面的3主3从集群。
4.1 集群发现：MEET
最开始时，每个Redis实例自己是一个集群，我们通过cluster meet让各个结点互相“握手”。这也是Redis Cluster目前的一个欠缺之处：缺少结点的自动发现功能。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
4.2 角色设置：REPLICATE
结点全部“握手”成功后，就可以用cluster replicate命令为结点指定角色了，默认每个结点都是Master。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
4.3 槽指派：ADDSLOTS
设置好主从关系之后，就可以用cluster addslots命令指派16384个槽的位置了。有点恶心的是，ADDSLOTS命令需要在参数中一个个指明槽的ID，而不能指定范围。这里用Bash 3.0的特性简化了，不然就得用Bash的循环来完成了：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
这样我们就通过手动执行命令得到了与之前一样的集群。
4.4 数据迁移：MIGRATE
真正开始Resharding之前，redis-trib会先在源结点和目的结点上执行cluster setslot <slot> importing和cluster setslot <slot> migrating命令，将要迁移的槽分别标记为迁出中和导入中的状态。然后，执行cluster getkeysinslot获得Slot中的所有Key。最后就可以对每个Key执行migrate命令进行迁移了。槽迁移完成后，执行cluster setslot命令通知整个集群槽的指派已经发生变化。
关于迁移过程中的数据访问，客户端访问源结点时，如果Key还在源结点上就直接操作。如果已经不在源结点了，就向客户端返回一个ASK错误，将客户端重定向到目的结点。
4.5 内部数据结构
Redis Cluster功能涉及三个核心的数据结构clusterState、clusterNode、clusterLink都在cluster.h中定义。这三个数据结构中最重要的属性就是：clusterState.slots、clusterState.slots_to_keys和clusterNode.slots了，它们保存了三种映射关系：
- clusterState：集群状态
- nodes：所有结点
- migrating_slots_to：迁出中的槽
- importing_slots_from：导入中的槽
- slots_to_keys：槽中包含的所有Key，用于迁移Slot时获得其包含的Key
- slots：Slot所属的结点，用于处理请求时判断Key所在Slot是否自己负责
- clusterNode：结点信息
- slots：结点负责的所有Slot，用于发送Gossip消息通知其他结点自己负责的Slot。通过位图方式保存节省空间，16384/8恰好是2048字节，所以槽总数16384不是随意定的。
- clusterLink：与其他结点通信的连接
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
4.6 处理流程全梳理
在单机模式下，Redis对请求的处理很简单。Key存在的话，就执行请求中的操作；Key不存在的话，就告诉客户端Key不存在。然而在集群模式下，因为涉及到请求重定向和Slot迁移，所以对请求的处理变得很复杂，流程如下：
- 检查Key所在Slot是否属于当前Node？
2.1 计算crc16(key) % 16384得到Slot
2.2 查询clusterState.slots负责Slot的结点指针
2.3 与myself指针比较 - 若不属于，则响应MOVED错误重定向客户端
- 若属于且Key存在，则直接操作，返回结果给客户端
- 若Key不存在，检查该Slot是否迁出中？(clusterState.migrating_slots_to)
- 若Slot迁出中，返回ASK错误重定向客户端到迁移的目的服务器上
- 若Slot未迁出，检查Slot是否导入中？(clusterState.importing_slots_from)
- 若Slot导入中且有ASKING标记，则直接操作
- 否则响应MOVED错误重定向客户端
5.应用案例收集
5.1 有道：Redis Cluster使用经验
详情请参见原文，关键内容摘录如下：
5.1.1 两个缺点
“redis cluster的设计在这块有点奇葩，跟集群相关的操作需要一个外部的ruby脚本来协助（当然可能是为了让主程序的代码足够简洁？），然后那个脚本还只支持填实例的ip不支持host，还不告诉你不支持让你用host之后各种莫名其妙。”
“第一个缺点就是严格依赖客户端driver的成熟度。如果把redis cluster设计成类似Cassandra，请求集群中任何一个节点都可以负责转发请求，client会好写一些。”
“第二个缺点完全是设计问题了，就是一个redis进程既负责读写数据又负责集群交互，虽然设计者已经尽可能简化了代码和逻辑，但还是让redis从一个内存NoSQL变成了一个分布式NoSQL。分布式系统很容易有坑，一旦有坑必须升级redis。”
5.1.2 去中心化 vs. Proxy
“关于redis cluster的设计，Gossip/P2P的去中心化架构本身不是问题，但一旦有了中心节点，能做的事情就多了，比如sharding不均匀是很容易自动rebalance的，而无中心的只能靠外界来搞。然后redis cluster又是slot的形式而非C*式的一致性哈希，新节点分slot又不自动，依赖外界（ruby脚本）来分配显得不方便更不优美和谐。而且因为是master-slave的系统而非W+R>N的那种，master挂掉之后尽快发现是比较重要的，gossip对于节点挂掉的发现终究没有中心节点/zookeeper方便快速。”
“基于proxy做转发意味着屏蔽了下层存储，完全可以根据前缀/tag/冷热程度，来把部分甚至大多数数据放在磁盘从而节约成本又保证一致性，这都是有中心节点所带来的好处。”
5.2 奇虎360：Redis Cluster浅析和Bada对比
详情请参见原文，关键内容摘录如下：
5.2.1 负载均衡问题
“redis cluster的主备是以节点为单位，而bada则是以partition为单位，这样，同样是3个节点，1024个partition的情况下，redis cluster的主节点负责整个1024个partition的服务，而两个从节点则只负责异步备份，导致集群负载不均，再看bada，将1024个partition的主均分到3个节点中，每个节点各有主备，主对外提供服务，这样均分了访问压力，有效的利用了资源。”
5.2.2 一致性的保证
“redis cluster与bada一样，最终一致性，读写都只请求主节点，当一条写请求在对应的主节点写成功后，会立刻返回给客户端成功，然后主节点通过异步的方式将新的数据同步到对应的从节点，这样的方式减少了客户端多个节点写成功等待的时间，不过在某些情况下会造成写丢失：
1）当主节点接受一条写请求，写入并返回给客户端成功后不幸宕掉，此时刚才的写还未同步给其对应的从节点，而从节点在发现主节点挂掉并重新选主后，新的主节点则永久丢失了之前老的主节点向用户确认的写
2）当网络发生割裂，将集群分裂成少数派与多数派，这样在客户端不知情的情况下，会将写继续写入到少数派中的某些主节点中，而当割裂超过一定时长后，集群感知到异常，此时少数派中的所有主节点会停止响应所有的写请求，多数派的其对应的从节点则会发起选举成为新的主节点，假设过了一会后割裂恢复，老的主节点发现有更新的主存在，自动变成其从节点，而新的主节点中则会永久丢失掉网络割裂至集群感知异常进行切主这个阶段老主节点确认的所有写
相对于redis cluster的永久丢失，bada通过binlog merge有效的解决了这一问题。所有partition的主节点在响应客户端的写请求时，都会在本地记录binlog，binlog实质就是带有时间戳的KV对。当老主以从节点的身份重新加入集群时，会触发binlog merge操作，新主会比较并且合并二者的binlog，这样就可以将之前丢失掉得写再补回来。”
5.2.3 请求重定向问题
“bada服务端节点在收到本不该由自己负责的Partition请求后，不会向客户端返回重定向信息，而是通过代理的方式，直接在集群内部向正确节点转发客户端的请求，并将结果同meta信息再转发回客户端。”
“再看multi key操作，redis cluster为了追求高性能，支持multi key的前提是所有的key必须在同一个节点中, 不过这样的处理需要交给用户，对需要进行multi key操作的所有key，在写入前人为的加上hash tags。当redis cluster进行resharding的时候，也就是将某些slot从一个节点迁移到另一个节点时，此时的multi key操作可能会失败，因为在迁移的slot中的key此时存在于两个节点。
bada怎么做呢？用户如果对multi key操作性能很在乎时，可以采用与redis cluster同样的方式，给这些key加上hash tags来让它们落在同一个节点，如果可以接受性能的稍微损耗而解放用户的处理逻辑，则可以像single key操作一样，请求任一bada节点，它会代理所有的key请求并将结果返回给用户。并且在multi key操作在任何时候都可以，即使在进行partition的迁移，bada也会提前进行切主，保证服务的正常提供。”
5.3 芒果TV：Redis服务解决方案
详情请参见原文，关键内容摘录如下：
芒果TV在Redis Cluster基础上进行开发，主要增加了两个组件：
- 监控管理：以Python为主要开发框架的Web应用程序Redis-ctl
- 请求代理：以C++11为开发语言的轻量数据代理程序cerberus。其作用和优点为：
- 集群代理程序的自动请求分发/重试机制使得应用不必修改自身代码或更新Redis库
- 代理节点为所有Redis节点加上统一管理和状态监测, 可以查阅历史数据, 或在发生任何问题之后快速响应修复
- 代理进程的无状态性使之可在故障后快速恢复, 不影响后端集群数据完整性
这两个组件都已开源到GitHub上，大家可以关注一下！
6.Pros & Cons总结
关于Redis Cluster带来的种种优势就不说了，在这里主要是“鸡蛋里挑骨头”，总结一下现阶段集群功能的欠缺之处和可能的“坑”。
6.1 无中心化架构
6.1.1 Gossip消息
Gossip消息的网络开销和时延是决定Redis Cluster能够线性扩展的因素之一。关于这个问题，在《redis cluster百万QPS的挑战》一文中有所提及。
6.1.2 结点粒度备份
此外，Redis Cluster也许是为了简化设计采用了Master-Slave复制的数据备份方案，并没有采取如Cassandra或IMDG等对等分布式系统中常见的Slot粒度（或叫Partition/Bucket等）的自动冗余和指派。
这种设计虽然避免比较复杂的分布式技术，但也带来了一些问题：
- Slave完全闲置：即便是读请求也不会被重定向到Slave结点上，Slave属于“冷备”
- 写压力无法分摊：Slave闲置导致的另一个问题就是写压力也都在Master上
6.2 客户端的挑战
由于Redis Cluster的设计，客户端要担负起一部分责任：
- Cluster协议支持：不管Dummy还是Smart模式，都要具备解析Cluster协议的能力
- 网络开销：Dummy客户端不断重定向的网络开销
- 连接维护：Smart客户端对连接到集群中每个结点Socket的维护
- 缓存路由表：Smart客户端Slot路由表的缓存和更新
- 内存消耗：Smart客户端上述维护的信息都是有内存消耗的
- MultiOp有限支持：对于MultiOp，由客户端通过KeyTag保证所有Key都在同一Slot。而即便如此，迁移时也会导致MultiOp失败。同理，对Pipeline和Transaction的支持也受限于必须操作同一Slot内的Key。
6.3 Redis实现问题
尽管属于无中心化架构一类的分布式系统，但不同产品的细节实现和代码质量还是有不少差异的，就比如Redis Cluster有些地方的设计看起来就有一些“奇葩”和简陋：
- 不能自动发现：无Auto Discovery功能。集群建立时以及运行中新增结点时，都要通过手动执行MEET命令或redis-trib.rb脚本添加到集群中
- 不能自动Resharding：不仅不自动，连Resharding算法都没有，要自己计算从哪些结点上迁移多少Slot，然后还是得通过redis-trib.rb操作
- 严重依赖外部redis-trib：如上所述，像集群健康状况检查、结点加入、Resharding等等功能全都抽离到一个Ruby脚本中了。还不清楚上面提到的缺失功能未来是要继续加到这个脚本里还是会集成到集群结点中？redis-trib也许要变成Codis中Dashboard的角色
- 无监控管理UI：即便未来加了UI，像迁移进度这种信息在无中心化设计中很难得到
- 只保证最终一致性：写Master成功后立即返回，如需强一致性，自行通过WAIT命令实现。但对于“脑裂”问题，目前Redis没提供网络恢复后的Merge功能，“脑裂”期间的更新可能丢失
6.4 性能损耗
由于之前手头没有空闲的物理机资源，所以只在虚拟机上做了简单的单机测试，在单独的一台压力机使用YCSB测试框架向虚拟机产生读写负载。虚拟机的配置为8核Intel Xeon CPU X5650@2.67GHz，16GB内存，分别搭建了4结点的单机版Redis和集群版Redis，测试一下Redis Cluster的性能损耗。由于不是最近做的测试，所以Jedis用的2.6.2版本。注：当然Redis Cluster可以通过多机部署获得水平扩展带来的性能提升，这里只是由于环境有限所以做的简单单机测试。
由于YCSB本身仅支持Redis单机版，所以需要我们自己增加扩展插件，具体方法请参照《YCSB性能测试工具使用》。通过YCSB产生2000w随机数据，Value大约100Byte左右。然后通过YCSB测试Read-Mostly(90% Read)和Read-Write-Mixed(50% Read)两种情况：
- 数据加载：吞吐量上有约18%的下降。
- Read-Mostly：吞吐量上有约3.5%~7.9%的下降。
- Read-Write-Mixed：吞吐量上有约3.3%~5.5%下降。
- 内存占用：Jedis客户端多占用380MB内存。
6.5 最后的总结
从现阶段看来，相比Sentinel或Codis等方案，Redis Cluster的优势还真是有限，个人觉得最大的优点有两个：
- 官方提供的Slot实现而不用像Codis那样去改源码了；
- 不用额外的Sentinel集群或类似的代码实现了。
同其他分布式系统，如Cassandra，或内存型的IMDG如Hazelcast和GridGain，除了性能方面外，从功能上Redis Cluster简直被爆得体无完肤… 看看我之前总结过的GridGain介绍《开源IMDG之GridGain》：
- 结点自动发现和Rebalance
- 分区粒度的备份
- 故障时分区角色自动调整
- 结果聚合（不会重定向客户端）
- “脑裂”恢复后的Merge（Hazelcast支持多种合并策略）
- 多Primary分区写操作（见Replicated模式）
这些都是Redis Cluster没有或者要手动完成的。当然这也不足为奇，因为这与Redis的设计初衷有关，毕竟作者都已经说了，最核心的设计目标就是性能、水平伸缩和可用性。
从Redis Cluster的环境搭建使用到高级功能和内部原理剖析，再到应用案例收集和优缺点的分析罗列，讲了这么多，关于Redis集群到底如何，相信大家根据自己切身和项目的具体情况一定有了自己的结论。不管是评估测试也好，二次开发也好，还是直接上线使用也好，相信随着官方的不断迭代更新和大家的力量，Redis Cluster一定会逐渐完善成熟的！
置顶卡
沉默卡
千斤顶
楼主
/4 
