1、读写分离、分库分表

1-1 海量数据的存储与访问瓶颈解决方案-数据切分

背景

在当今这个时代，人们对互联网的依赖程度非常高，也因此产生了大量的数据，企业视这些数据为瑰宝。而这些被视为瑰宝的数据为我们的系统带来了很大的烦恼。这些海量数据的存储与访问成为了系统设计与使用的瓶颈，而这些数据往往存储在数据库中，传统的数据库存在先天的不足，即单机(单表)性能瓶颈，而且扩展起来非常困难。在当今的这个大数据时代，我们急需解决这个问题。如果单机数据库易于扩展，数据可切分，就可以避免这些问题，但是当前这些数据库厂商，包括开源的MySQL在内，提供这些服务都是需要收费的，所以我们转向一些第三方的软件，使用这些软件做数据的切分，将原来在一台数据库上的数据，分散到多台数据库当中，降低每一个单体数据库的负载。那么我们如何做数据切分呢？

数据切分

数据切分，简单来说，就是通过某种条件，将我们之前存储在一台数据库上的数据，分散到多台数据库中，从而达到降低单台数据库负载的效果。数据切分，根据其切分规则，大致分为两种类型，垂直切分和水平切分。

垂直切分

垂直切分就是按照不同的表或者Schema切分到不同的数据库中，比如：订单表(order)和商品表(product)在同一个数据库中，而我们现在要对其切分，使得订单表(order)和商品表(product)分别落到不同的物理机中的不同数据库中，使其完全隔离，从而达到降低数据库负载的效果。如下图所示：

垂直切分的特点就是规则简单，易于实施，可以根据业务模块进行划分，各个业务之间耦合性低，相互影响也比较小。

一个架构设计较好的应用系统，其总体功能肯定是由多个不同的功能模块组成的。每个模块对应着数据库里的一系列表。例如商品功能模块对应的表包括：类目、属性、属性值、品牌、商品、sku等表。而在订单模块中，对应的表包括：订单、订单明细、订单收货地址、订单日志等。如图所示：

在架构设计中，各个功能模块之间的交互越统一、越少越好。这样，系统模块之间的耦合度会很低，各个系统模块的可扩展性、可维护性也会大大提高。这样的系统，实现数据的垂直切分就会很容易。

但是，在实际的系统架构设计中，有一些表很难做到完全的独立，往往存在跨库join的现象。还是上面的例子，比如我们接到了一个需求，需要查询某一个类目产生了多少订单，如果在单体数据库中，我们直接连表查询就可以了。但是现在垂直切分为两个数据库，跨库连表查询是十分影响性能的，也不推荐这样用，只能通过接口去调取服务，这样系统的复杂度又升高了。对于这种很难做到完全独立的表，作为系统架构设计人员，就要做平衡，是数据库让步于业务，将这些表放在一个数据库当中？还是拆分成多个数据库，业务之间通过接口来调用呢？在系统初期，数据量比较小，资源也有限，往往会选择放在一个数据库当中。而随着业务的发展，数据量达到一定的规模，就有必要进行数据的垂直切分了。而如何进行切分，切分到什么程度，则是对架构师的一个艰难考验。

下面我们来看看垂直切分的优缺点：

优点：

拆分后业务清晰，拆分规则明确；
系统之间容易扩展和整合；
数据维护简单；

缺点：

部分业务表无法join，只能通过接口调用，提升了系统的复杂度；
跨库事务难以处理；
垂直切分后，某些业务数据过于庞大，仍然存在单体性能瓶颈。

正如缺点中的最后一条所说，当某一个业务模块的数据暴增时，仍然存在着单机性能缺陷。还是之前的例子，如果出现了一个爆款商品，订单量急剧上升，达到了单机性能瓶颈，那么你所有和订单相关的业务都要收到影响。这时我们就要用到水平切分。

水平切分

水平切分相比垂直切分，更为复杂。它需要将一个表中的数据，根据某种规则拆分到不同的数据库中，例如：订单尾号为奇数的订单放在了订单数据库1中，而订单尾号为偶数的订单放在了订单数据库2中。这样，原本存在一个数据库中的订单数据，被水平的分为两个数据库。在查询订单的时候，我们还要根据订单的尾号，判断这个订单在数据库1中，还是在数据库2中，然后将这条SQL语句发送到正确的数据库中，查出订单。水平切分的架构图如下：

水平拆分数据，要先确定拆分规则，找到你要按照哪个维度去拆分，还是前面订单的例子，我们按照订单尾号的奇偶去拆分，那么这样拆分会有什么影响呢？假如我是一个用户，我下了两个订单，一个订单尾号为奇数，一个订单尾号为偶数，这时，我去个人中心，订单列表页去查看我的订单。那么这个订单列表页要去怎么查，要根据我的用户id分别去订单1库和订单2库查询出数据，然后再合并成一个列表，是不是很麻烦。所以，咱们在拆分数据时，一定要结合业务，选择出适合当前业务场景的拆分规则。那么按照用户id去拆分数据就合理吗？也不一定，比如：咱们的身份变了，不是买家了，而是卖家，我这个卖家有很多的订单，卖家的后台系统也有订单列表页，那这个订单列表页要怎么去查？是不是也要在所有的订单库中查一遍，然后再聚合成一个订单列表页呀，那这样看，是不是按照用户id去拆分订单又不合理了。所以在做数据水平拆分时，是对架构师的真正考验。

我们看看几种水平拆分的典型分片规则：

用户id求模；
按照日期去拆分数据；
按照其它字段求模，去拆分数据。

上面是按照用户id去求模拆分的一个示意图。

咱们再来看看水平拆分的优缺点：

优点：

解决了单库大数据、高并发的性能瓶颈；
拆分规则封装好，对应用端几乎透明，开发人员无需关心拆分细节；
提高了系统的稳定性和负载能力；

缺点：

拆分规则很难抽象；
分片事务一致性难以解决；
二次扩展时，数据迁移、维护难度大。比如：开始我们按照用户用户id对2求模，但是随着业务的增长，2台数据库难以支撑，还是继续拆分成4个数据库，那么这时就要做数据迁移了。

总结

世界上的万物没有完美的，有利就有弊，就像数据切分一样。无论是垂直切分，还是水平切分，它们解决了海量数据的存储和访问性能的问题，但也随之而来的带来了很多新的问题，它们共同的缺点有：

分布式的事务问题；
跨库join问题；
多数据源的管理问题

针对多数据源的管理问题，主要有两种思路：

客户端模式，在每个应用模块内，配置自己需要的数据源，直接访问数据库，在各个模块内完成数据的整合；
中间代理模式，中间代理统一管理所有的数据源，数据库层对开发人员完全透明，开发人员无需关注拆分细节。

基于这两种模式，目前都有成熟的第三方软件，接下来我会介绍这两种模式的代表作：

中间代理模式：MyCat
客户端模式：Sharding-JDBC

1-2 如何正确的使用数据库读写分离

背景

在应用系统发展的初期，我们并不知道以后会发展成什么规模，所以一开始不会考虑复杂的系统架构，复杂的系统架构费时费力，开发周期长，与系统发展初期这样的一个定位是不吻合的。所以，我们会采用简单的架构，随着业务的不断发展，访问量不断升高，我们再对系统进行架构方面的优化。

架构演进

系统建立初期，我们的架构都非常的简单，主要满足业务的正常运行，如图：

但是随着访问量的升高，人们对系统的可靠性有了更高的要求，所以，我们为了避免单点故障，对系统应用层进行了横向的扩展，如图：

这样，保证了系统应用层的高可用，在发生宕机，或者系统升级时，系统对外还是可用的。而且在访问量升高的时候，系统应用层的压力也会得到分摊，使得每一个单体的系统应用的压力在一个合理的区间范围内。

但是，随着访问量的升高，所有的压力都将集中到数据库这一层。那么数据库这一层，我们要要怎么处理呢？能不能像系统应用层那样进行扩展呢？答案当然是否定的，我们想象一下，如果数据库层也像系统应用层那样，进行横向扩展，如图：

那么，如果系统应用层产生了一条数据，这条数据应该插入DB1还是DB2呢？假设插入了DB1，那么这条数据被读取时，应用层怎么知道从哪个数据库读取这条数据呢？问题是不是很复杂，如果数据库不进行扩展，那么一台数据库是承载不了这么大的访问量，那我们怎么办呢？

数据库读写分离

办法总比问题多，随着互联网技术的发展，以及一代代互联网人的深入研究，人们发现在互联网的系统应用是一个读多写少的应用，比如电商系统，商品浏览的次数都是比下单的要多。数据库承载压力大，主要是由这些读的请求造成的，那么我们是不是可以把读操作和写操作分开，让所有读的请求落到专门负责读的数据库上，所有写的操作落到专门负责写的数据库上，写库的数据同步到读库上，这样保证所有的数据修改都可以在读取时，从读库获得，系统的架构如下图所示：

如果系统的读请求比较多的话，读库可以多部署几台，这样读请求就可以均摊到多台读库上，降低每一个读库的压力。但是在写数据的时候，数据要落在一个确定，且唯一的写库中。上图中，咱们的写库只有一个，你当然可以部署多个写库，但是数据怎么分片是一个十分重要的问题，这个问题我们在后续会做介绍。目前仅以一个写库为例，比如：商户发布商品时，讲这个商品的数据落在了写库上，同时，写库将这条数据同步给两个读库，买家在网站浏览商品时，会从读库将这个商品数据读取。至于从哪个读库取出数据，那就要看这个请求在当时的路由情况了。

总之，将大量的读操作从数据库中剥离，让读操作从专用的读数据库中读取数据，大大缓解了数据库的访问压力，也使得读取数据的响应速度得到了大大的提升。那么读写分离有什么弊端吗？是不是所有的场景都适用读写分离这种架构呢？

读写分离的弊端

读写分离给我们带来的好处是很多的，我们对比一下原始的架构和读写分离的架构，从数据流上看，他们的区别是，数据从写入到数据库，到从数据库取出，读写分离的架构多了一个同步的操作。大家想一想，同步操作的时间是多少，延迟如果太大对系统有没有影响，如果同步挂了怎么办？我举一个亲身经历的案例，那时我们在做一个个人中心的订单列表页，这个功能挺简单，只需要把订单数据取出来，在页面上展示就可以了。但是在做的时候，订单以及订单相关的数据都是从读库中取出的，其中就包括支付状态，这个用户非常敏感的字段。就在某一天的某一个时段，突然接到了用户的大量投诉，说用户已经付了钱，但是订单状态就是未支付。我也觉得很奇怪，马上要了一个订单号，去数据库里查询，发现订单状态就是未支付呀，没有问题，过了一会儿，为了保险起见，我还是去写库再查一下这个订单吧，发现写库的订单状态确实是已支付，这下完了，写库和读库取的数据不一致，我马上通知DBA，让他们查数据库，他们的反馈是同步挂掉了。

大家看到了吧，这就是读写分离的弊端，当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致，这个数据的不一致，用户能不能接受，订单支付状态这个不一致当然是不能接受的了，其他的业务场景就要根据业务场景具体分析了。

如何正确的使用读写分离

一些对数据实时性要求不高的业务场景，可以考虑使用读写分离。但是对数据实时性要求比较高的场景，比如订单支付状态，还是不建议采用读写分离的，或者你在写程序时，老老实实的从写库去读取数据。这里给出的建议是，如果你做数据的同步，你的网络延迟应该在5s以内，这个对网络环境要求是非常高的，大家可以ping一下你的网络中的其他机器，看看能不能达到这个标准。如果你的网络环境很好，达到了要求，那么使用读写分离是没有问题的，数据几乎是实时同步到读库，根本感觉不到延迟。

2-1 MyCat概述与基本概念

什么是MyCat

MyCat是什么？从定义和分类来看，他是一个开源的分布式数据库系统，前端的用户可以把它看成一个数据库代理，用Mysql客户端和命令工具都可以访问，而其后端是用Mysql原生的协议与多个Mysql服务之间进行通信。MyCat的核心功能就是分库分表，即将一个大水表水平切分成N个小表，然后存放在后端的Mysql数据中。

对于DBA来说，可以这样理解MyCat：

MyCat就是Mysql，而MyCat后面连接的Mysql，可以理解为Mysql中的存储引擎，比如：MyISAM、InnoDB。所以，MyCat本身不存储数据，数据都是存储在MyCat后面连接的Mysql上，数据的可靠性和事务都是Mysql保证的。

对于开发人员来说，可以这样理解MyCat：

MyCat就是一个近似等于MySql的数据库库服务，你可以使用连接MySql的方式连接MyCat。绝大多数情况，你也可以使用常用的ORM框架连接MyCat，但是，对于分片的表，还是建议使用标准SQL语句，这样能够达到最佳的性能。

对于架构师来说，可以这样理解MyCat：

MyCat是一个强大的数据库中间件，不仅仅可以用作读写分离，分库分表，还可以用于容灾备份，云平台建设等，让你的架构具备很强的适应性和灵活性。

MyCat的应用场景：

1.单纯的读写分离，此时配置最为简单，支持读写分离，主从切换；

2.分库分表，对于超过1000w的表进行分片，最大支持1000亿的数据；

3.多租户应用，每个应用一个数据，应用只连接MyCat，程序本身不需要改造；

4.替代HBase，分析大数据。

MyCat中的基本概念

MyCat是一个数据库的中间件，介于应用与数据库之间，是进行数据处理和交互的中间服务。正是由于它是一个数据库代理的中间件。

逻辑库（Schema）

在实际的开发中，开发人员不需要知道数据库中间件的存在，开发人员只需要有数据库的概念就可以了。所以数据库中间件可以被看做是一个或者多个数据库集群构成的逻辑库。例如：上图中的例子，我们可以理解为系统先做了垂直切分，被分为了3个库，用户库，订单库，商品库，而这3个库就被称为逻辑库。

逻辑表（table）

既然有逻辑库，那么就有逻辑表，对于应用系统来说，读写数据的表，就是逻辑表。而逻辑表中的数据，则是被水平切分后，分布在不同的分片库中。如上图所示：假设用户库中有一张用户表，这个用户表就被称为逻辑表，而用户表又被水平切分为3个表，每一个表中都存储一部分用户数据。业务系统在进行用户数据的读写时，只需要操作逻辑表就可以了，后面的分片细节则由MyCat进行操作，这些对于业务开发人员来说时完全透明的。当然，有些表的数据量没有那么大，完全不需要进行分片，只在一个物理的数据库表中即可。

凡是我们做的数据水平切分的表，我们把它叫做分片表。而数据量比较小，没有进行分片的表，我们叫他非分片表。

在真实的业务系统中，往往存在着大量的字典表，这些表的数据基本上很少变动，比如：订单状态。我们查询的时候，往往需要关联字典表去查询，比如：查询订单时，需要把订单状态关联查出，如果订单表做了分片，分布在不同的数据库中，而订单状态表由于数据量小，没有做分片，那么我们查询的时候就要跨库关联查询订单状态，增加了不必要的麻烦，不如我们干脆把订单状态表冗余到所有的订单分片库中，这样关联查询就不需要跨库了。我们把这种通过数据冗余方式复制到所有的分片库中的表，叫做全局表。

分片节点（dataNode）

数据被切分后，一张大表被分到不同的分片数据库上面，每个分片表所在的数据库就叫做分片节点。

节点主机（dataHost）

数据切分后，每一个分片节点不一定都会占用一个真正的物理主机，会存在多个分片节点在同一个物理主机上的情况，这些分片节点所在的主机就叫做节点主机。为了避免单节点并发数的限制，尽量将读写压力高的分片节点放在不同的节点主机上。

分片规则（rule）

一个大表被拆分成多个分片表，就需要一定的规则，按照某种业务逻辑，将数据分到一个确定的分片当中，这个规则就叫做分片规则。数据切分选择合适的分片规则非常重要，这将影响到后的数据处理难度，结合业务，选择合适的分片规则，是对架构师的一个重大考验。对于架构师来说，选择分片规则是一个艰难的，难以抉择的过程。

全局序列号（sequence）

大家有没有想过，数据切分以后，数据库表的中的id怎么办？原来在一张表的时候，我们采用id自增，但是数据分布到多个库怎么办？比如：向用户表插入数据，第一条记录插入了用户库1，它的id为1；第二条记录插入了用户库2，如果是自增，它的id也为1。这样id就混乱了，我们也无法确定一条数据的唯一标识了。这时，我们需要借助外部的机制保证数据的唯一标识，这种保证数据唯一标识的机制，我们叫做全局序列号。

2-2 MyCat-Mysql环境搭建

三台虚拟机：192.168.73.130、192.168.73.131、192.168.73.132

我们在192.168.73.130上安装MyCat，在另外两台上安装MySQL。

2-2-1 安装Mysql

2-2-1-1 查询释放安装了mysql

rpm -qa|grep mysql

2-2-1-2 卸载mysql（下面是卸载mysql的库，防止产生冲突，mysql也是类似卸载方式）

rpm -e --nodeps mysql-libs-5.1.* 卸载之后，记得： find / -name mysql 删除查询出来的所有东西

2-2-1-3 安装mysql

yum install mysql-server

注意：centos7这样安装不行

2-2-1-4 启动 mysql

启动方式1：service mysql start 启动方式2：/etc/init.d/mysql start 启动方式3：service mysqld start 启动方式4：/etc/init.d/mysqld start

2-2-1-5 root账号默认是没有密码的，修改root密码：

/usr/bin/mysqladmin -u root password 密码例如：/usr/bin/mysqladmin -u root password pwd 这样就将root密码设置成pwd了

2-2-1-6 重置root密码（忘记root密码找回）

2-2-1-6-1 停止mysql服务命令：

/etc/init.d/mysqld stop /etc/init.d/mysql stop

2-2-1-6-2 输入绕过密码认证命令：

mysqld_safe --user=mysql --skip-grant-tables --skip-networking &

2-2-1-6-3 输入登录用户命令

mysql -u root mysql

2-2-1-6-4 输入修改root密码SQL语句：

update user set Password=password ('123456') where user='root';

2-2-1-6-5 输入数据刷新命令：

FLUSH PRIVILEGES;

2-2-1-6-6 退出Mysql命令：

quit;

2-2-1-7 设置允许远程连接

grant all privileges on *.* to root@'%' identified by '123456789' with grant option;

2-2-1-8 开放端口3306，否则依然无法远程连接

2-2-1-8-1 打开防火墙配置文件：

vi /etc/sysconfig/iptables

2-2-1-8-2 添加下面一行：

-A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT

注意：开通3306端口的行必须在icmp-host-prohibited前，否则无效：以下为配置结果：

2-2-1-8-3 重启防火墙，使配置生效：

/etc/init.d/iptables restart

2-2-1-9 设置开机启动mysql：

2-2-1-9-1 查看mysql服务是否自动开启命令

chkconfig --list | grep mysqld chkconfig --list | grep mysql

2-2-1-9-2 开启mysql服务自动开启命令

chkconfig mysqld on chkconfig mysql on

2-2-1-10 将mysql默认引擎设置为InnoDB

2-2-1-10-1 修改mysql配置文件my.cnf

cd /etc vi my.cnf

2-2-1-10-2 在[mysqld]一段加入

default-storage-engine=InnoDB

2-2-1-10-3 删除ib_logfile0、ib_logfile1两个文件

cd /var/lib/mysql rm -rf ib_logfile*

2-2-1-10-4 重启mysql

2-2-1-11 开启mysql的日志（监控执行的sql语句）

2-2-1-11-1 命令

show global variables like ‘%general%’；该语句可以查看是否开启，以及生成位置 set global general_log = on; // 打开 set global general_log = off; // 关闭

2-2-1-11-2 参考文档：

mysql general log_傲雪星枫的博客-CSDN博客

2-2-2 centos7安装mysql

wget http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm

#rpm -ivh mysql-community-release-el7-5.noarch.rpm

#yum install mysql-community-server 成功安装之后重启mysql服务

#service mysqld restart 初次安装mysql是root账户是没有密码的设置密码的方法

#mysql -uroot

mysql> set password for ‘root’@‘localhost’ = password('mypasswd'); mysql> exit

2-3 MyCat安装

官网：http://mycat.org.cn/

下载地址：http://dl.mycat.org.cn/1.6.7.5/2020-4-10/

上传mycat压缩包到192.168.73.130主机上。

解压：

进入mycat目录：

修改配置文件：

修改server.xml

修改schema.xml

修改dataHost:

再复制一个dataHost到下面也相应的改一下：

配置dataNode:

配置schema：

在数据库中创建表：

修改autopartition-long.txt

注释掉最后一个节点(因为我们只有两个数据库节点)

启动myCat服务：

启动成功：

使用Navicat连接MyCat(注意端口是8066)

MyCat的配置文件

server.xml--基础配置

配置Mycat用户
- 一个 <user> 表示一个用户
- 里面可以设置用户名name，用户密码password
- 设置了 "readOnly" 表示改用户只能读，不能对数据库内容进行修改
- 配置的 “schemas”要和 schemas.xml文件中匹配的schema对应起来
  - 配置个schemas 可以使用逗号隔开
- Macat的加密方式
  - Mysql8.0使用的新的加密方式;
  - Nactive和MyCat使用的都是老版的加密方式，所以Navicat可以直接连MyCat，而Mysql8.0需要将密码设置成为 Navicat连接方式;
    - 使用navicat连接mycat可以
    - 使用mysql8.0的命令行连接mycat，不能连接
      - 可以使用指定老加密方式

后台启动mycat

./mycat start

mycat修改配置文件，可以不用重启

采用9066管理端口

可以重新加载配置文件

reload @@Config；

如果修改了数据源的配置，需要采用reload @@config_all;

停掉mysql

systemctl stop mysqld

1、读写分离、分库分表相关推荐

视频教程-ShardingSphere:SpringBoot2+MybatisPlus+读写分离+分库分表-Java
ShardingSphere:SpringBoot2+MybatisPlus+读写分离+分库分表 10多年互联网一线实战经验,现就职于大型知名互联网企业,架构师, 有丰富实战经验和企业面试经验:曾就职 ...
MySql高可用搭建 + 读写分离 + 分库分表
Mysql读写分离与分库分表一.Mysql读写分离解决的问题二.mysql处理请求运行流程三.读写分离结构四.读写分离产生场景五.读写分离工具 5.1 MyCat 5.2 HAProxy 5 ...
@mysql读写分离分库分表
文章目录 MySQL中间件Atlas 一 atlas简介二主要功能三使用场景四企业读写分离及分库分表其他方案了解五安装Atlas 六配置七启动服务 1) mysql库创建账号八 ...
Sharding-Jdbc 实现读写分离 + 分库分表，写得太好了！
欢迎关注方志朋的博客,回复"666"获面试宝典来自:CSDN,作者:邋遢的流浪剑客链接:https://blog.csdn.net/qq_40378034/article/de ...
MySQL搭建主从复制读写分离分库分表 MyCat高可用
主从演示读写演示分表演示主从复制环境的介绍系统环境:centos7.0 客户端连接工具:xshell 远程文件传输工具:xftp 服务器: 192.168.126.138(主) 192.16 ...
SpringCloud微服务实战——搭建企业级开发框架（二十七）：集成多数据源+Seata分布式事务+读写分离+分库分表
读写分离:为了确保数据库产品的稳定性,很多数据库拥有双机热备功能.也就是,第一台数据库服务器,是对外提供增删改业务的生产服务器:第二台数据库服务器,主要进行读的操作. 目前有多种方式实现读写分 ...
Mycat 读写分离+分库分表
上次进过GTID复制的学习记录,已经搭建好了主从复制的服务器,现在利用现有的主从复制环境,加上正在研究的Mycat,实现了主流分布式数据库的测试 Mycat就不用多介绍了,可以实现很多分布式数据库的功 ...
MyCAT读写分离分库分表
MyCAT读写分离及分库分表第1章 MyCAT分布式系统解决方案 1.1 分布式系统介绍: 分布式系统特性: 1. 透明性: a) 分布式系统对用户来说是透明的,一个分布式系统在用户面前的表现就像一 ...
数据库主从复制,读写分离,分库分表理解 (数据库架构演变)
主从复制主从复制, 主要是针对MySQL数据库的高可用性, 容灾性上面. 是叫做高可用性? 高可用性可以简单的理解为容灾性, 稳定性, 针对故障,风险情况下的处理, 备案, 策略. 指系 ...
商城订单模块实战 - 数据库设计、ABA问题处理、读写分离分库分表
引言订单系统可以说是整个电商系统中最重要的一个子系统,因此订单数据可以算作电商企业最重要的数据资产.这篇文章我们来看看在我们的商城系统中订单服务是如何实现的,特别是在设计和实现一个订单系统的过程中有 ...

1、读写分离、分库分表

1、读写分离、分库分表相关推荐

最新文章

热门文章