CN109831486A - 多客户端的后台数据服务器***及数据处理方法 - Google Patents

Abstract

本发明涉及网络数据处理技术领域，公开了一种多客户端的后台数据服务器***，包括服务器单元、和客户端单元，所述服务器单元包括数据中心，所述客户端单元包括若干个客户端子模块，所述客户端连接至服务器单元，所述数据中心包括缓存数据库和数据库集群，所述客户端子模块与所述服务器单元进行数据交换，所述服务器单元优先从缓存数据库中提取数据，如果缓存数据库中未提取到数据，则从数据库集群中查询提取，所述数据库集群根据服务器单元指令将数据同步至缓存数据库。本发明还公开了数据处理方法。本发明通过数据库层面上增加缓存数据库，提高了数据库承载能力。

Description

多客户端的后台数据服务器***及数据处理方法

技术领域

本发明涉及网络数据处理技术领域，具体涉及的是一种多客户端的后台数据服务器***及数据处理方法。

背景技术

在互联网业务场景下，访问量经常会面临十倍、百倍的上涨，传统单机数据库，单机服务器、甚至硬件升级(SSD)等手段无法在性能上有数量级的提升。随着互联网的发展，网站架构逐渐从集中式转变成分布式。

现在很多传统项目是单个应用，开发完毕打成一个war包，放在tomcat运行，对外提供服务。这种项目存在以下的问题：

1. 这样会产生扩展困难，耦合度较高，后续的开发难度较大，给开发人员带来了很大的一个困扰；

2. 收集日志简单，无法对日志进行详细具体的分析，无法从日志中提炼出有用的信息，对资源极其浪费；

3. 数据库为单机数据库，没有任何缓存策略，并发量一上来，数据库极易造成瘫痪；

4. 项目中锁使用的图片或者视频全部存在项目目录，一旦对项目进行集群的话，图片无法处理，而且对增加服务区磁盘压力。一旦图片被删除了，前端就显示不了了，没有备份图片。

发明内容

本发明的目的是为了解决上述问题，提供一种多客户端的后台数据服务器***及数据处理方法，通过数据库层面上增加缓存数据库，提高了数据库承载能力。

本发明采取的技术方案是：

一种多客户端的后台数据服务器***，其特征是，包括服务器单元、和客户端单元，所述服务器单元包括数据中心，所述客户端单元包括若干个客户端子模块，所述客户端连接至服务器单元，所述数据中心包括缓存数据库和数据库集群，所述客户端子模块与所述服务器单元进行数据交换，所述服务器单元优先从缓存数据库中提取数据，如果缓存数据库中未提取到数据，则从数据库集群中查询提取，所述数据库集群根据服务器单元指令将数据同步至缓存数据库。

进一步，所述服务器单元还包括注册中心，服务中心，日志中心，文件服务器，所述注册中心通过客户端实现配置维护；所述服务中心实现定时任务服务；所述日志中心启动线程和客户端连接，所述文件服务器实现文件存储、文件同步和文件访问。

进一步，所述数据中心的数据库集群为Mysql数据库集群，为一主多从模式，包括一个master节点，多个slave节点。

进一步，所述注册中心为zookeeper分布式协调服务组件。

进一步，所述服务中心包括产品服务，商家服务，支付服务，圈子服务，设备服务，用户服务，所述服务中心dubbo对外提供服务。

进一步，所述日志中心为集中式日志***，包括Elasticsearch、Logstash、Kibana中的一种开源软件。

进一步，所述文件服务器为分布式文件***FastDFS。

进一步，所述客户端子模块包括终端APP、管理***模块、网站终端、商家终端中的一个或多个。

进一步，所述客户端子模块连接有用户终端交互设备。

一种如上所述的多客户端的后台数据服务器***的数据处理方法，其特征是，包括如下步骤：

（1）客户端子模块与用户交互得到用户指令；

（2）客户端将指令发送至服务器单元；

（3）数据库集群根据指令进行数据同步至缓存数据库中；

（4）服务器单元从缓存数据库中提取数据；

（5）如果缓存数据提取失败，则从数据库集群中查询提取数据；

（6）服务器将数据返回至客户端；

（7）客户端将用户指令结果返回至用户终端。

本发明的有益效果是：

1.客户端和服务器之间增加了nginx反向代理服务器，nginx采用轮训的策略访问后台的服务，相当于后台服务之前加了一层屏障。健壮了后台的服务；

2.通过dubbo分布式框架对后台服务进行了业务性的拆分，让开发人员可以专门负责一部分，其中各个服务之间又是通过dubbo协议进行的通信。解决之前的单一项目造成的难扩展和后续开发问题；

3.采用了zookeeper注册中心，应用分布式锁，解决了分布式环境下，资源被多个线程持有，可能造成数据错乱的问题；

4.日志中心通过三个不同的组件实现，解决了之前简单日志收集的问题和无法对日志进行深度分析的问题；

5.数据库层面上增加缓存数据库，数据访问会先经过缓存数据库，如果缓存数据库中没有数据，才会访问数据库。这样解决了之前的单机数据库在并发量高的情况下极易宕机的问题，大大提高了数据库承载能力；

6.应用分布式文件服务器，图片存放是脱离项目的，项目服务做了集群，也不影响文件服务器的使用。另外，文件服务器storage节点做了集群，图片在多个storage节点做了备份，解决了之前单个项目图片一旦被删除前端就显示不了的问题。

附图说明

附图1是本发明的总体结构框图；

附图2是服务器架构示意图。

具体实施方式

下面结合附图对本发明多客户端的后台数据服务器***及数据处理方法的具体实施方式作详细说明。

参见附图1、2，多客户端的后台数据服务器***，包括服务器单元、和客户端单元，所述服务器单元包括数据中心、注册中心，服务中心，日志中心，文件服务器，所述客户端单元包括若干个客户端子模块，所述客户端连接至服务器单元，所述数据中心包括缓存数据库和数据库集群，所述客户端子模块与所述服务器单元进行数据交换，所述服务器单元优先从缓存数据库中提取数据，如果缓存数据库中未提取到数据，则从数据库集群中查询提取，所述数据库集群根据服务器单元指令将数据同步至缓存数据库。所述客户端子模块包括终端APP、管理***模块、网站终端、商家终端中的一个或多个。所述客户端子模块连接有用户终端交互设备。

多客户端的后台数据服务器***的数据处理方法包括如下步骤：

（1）客户端子模块与用户交互得到用户指令；

（2）客户端将指令发送至服务器单元；

（3）数据库集群根据指令进行数据同步至缓存数据库中；

（4）服务器单元从缓存数据库中提取数据；

（5）如果缓存数据提取失败，则从数据库集群中查询提取数据；

（6）服务器将数据返回至客户端；

（7）客户端将用户指令结果返回至用户终端。

继续参见附图1，本发明的***具体包括APP，管理***，商家端管理***，PC官网，微官网以及其各个子模块。都是通过一个后台服务器单元获取数据。

下面单独描述各个节点：

1.商家端管理后台是提供给商家使用的，商家可以在管理后台中，录入自己的产品，宣传视频，公司资料等等相关信息。该后台页面呈现使用的VUE框架。

2.管理后台是提供给自媒体的，用户可以登录该后台，发布自媒体文章，自媒体视频，自媒体图片，并且可以对这些自媒体进行修改查看。其中发布自媒体文章，是引用了百度的UEditor富文本插件，并对其进行了深度的定制二次开发，实现了捕捉图片，修改图片格式，上传视频等等符合公司业务的一些功能。

3. APP是开放给全网用户，给用户提供最佳商品购买方案的一款APP。里面支持对用户行为轨迹的监控，关键字搜索，支付宝微信付款，提现等等功能。

参见附图2，后台服务架构遵循SOA架构，是承载整个平台的核心，需要保证达到99.99%可用性，整体主要分为几个模块，分别是数据中心，注册中心，服务中心，日志中心，文件服务器。

各模块的具体情况如下：

数据中心：

数据中心分为mysql数据库集群和缓存数据库。后台服务拿取数据会先在缓存数据库中拿数据，如果缓存中没有的话，在查询mysql数据库。Mysql数据库集群是一主多从模式。一个master节点，多个slave节点。通过binlog日志进行数据同步。

数据库集群通过主从复制实现，并且实现了读写分离。Mysql的master节点会产生binlog日志，slave节点会启动一个IO线程，这个IO线程会和master建立一个普通的客户端连接。在master上会启动一个特殊的二进制转储线程，称之为binlog dump。从库上的IO线程会通过这个转储线程读取master节点binlog日志，写到自己的中继日志relaylog日志中。Slave节点会根据relaylog日志记录变更到自己的数据库中。

注册中心：

注册中心使用的Apache组织下的zookeeper，这是一款开源的分布式协调服务组件。本发明中使用到的分布式锁，发布/订阅，都是zookeeper的经典应用场景。Zookeeper数据结构，是一种树形的结构，其最小的节点是znode节点。

Znode总共有四种类型，分别是持久化节点，持久化有序节点，临时节点，临时有序节点。

本发明实现分布式锁是使用了zookeeper临时有序节点的特性。

举例如下：

A进程，B进程，C进程共同竞争一个资源，需要加上分布式锁，保证数据的一致性。具体实现步骤为：1.A，B，C三个进程分别在zookeeper的其中一个节点下面写一个临时有序；2.三个进程分别判断自己是否为这些临时节点的最小节点，如果是最小节点的话，则可以拿到锁，如果不是最小节点的话，在对其前一个节点添加一个watch（删除）事件；3.拿到锁的节点执行自己的业务逻辑，执行完毕之后session断开，该临时节点会删除，则会触发该节点的watch事件，执行2步骤。

服务中心：

服务中心由产品服务，商家服务，支付服务，圈子服务，设备服务，用户服务组成，服务中心向外提供服务。通过dubbo对外提供服务。产品服务中可以提供所有的产品相关接口，圈子服务可以提供所有自媒体圈子相关内容，包括自媒体文章和图片的发布，浏览，详情等等。其中支付服务，和支付宝，微信做了对接，可以对外提供的接口有充值接口，退款接口，转账接口，可以通过连接该服务调用相关接口，达到相关金钱的操作。

这里的服务中心使用的zookeeper，其他亦可以使用spring cloud的eurake，这里使用zookeeper主要是因为zookeeper对一致性和分区容错性做了很好的支持。本发明中使用的分布式RPC框架是阿里巴巴开源的dubbo框架，该框架可以很方便实现分布式治理相关内容。Dubbo框架也可spring框架做了很好的集成，使用过程中对用户非常友好。另外通过dubbo监控中心也是可以对各个服务调用和健康做很好的监控。定时任务服务可以提供分布式事务补偿机制，定时统计功能。

日志中心：

一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。

本发明很好的解决了这个问题，本发明使用了集中式日志***，组成包括：Elasticsearch , Logstash, Kibana三类开源软件，也是市面上很有名的ELK。

Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。

Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作再一起发往elasticsearch上去。

Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。

文件服务器

文件服务器使用的是分布式文件***FastDFS，FastDFS是一个开源的轻量级分布式文件***，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

FastDFS服务端有两个角色：***（tracker）和存储节点（storage）。***主要做调度工作，在访问上起负载均衡的作用。

本发明中的文件上传过程：

1. client询问tracker上传到的storage，不需要附加参数；

2. tracker返回一台可用的storage；

3. client直接和storage通讯完成文件上传。

本发明中的文件下载过程：

1. client询问tracker下载文件的storage，参数为文件标识（卷名和文件名）；

2. tracker返回一台可用的storage；

3. client直接和storage通讯完成文件下载。

该分布式文件服务器承担了平台所有的图片视频存储，对外提供文件上传下载API接口。

软负载

本发明在负载均衡策略上使用了Nginx软负载，即是在操作***上，安装一个附加软件来实现负载均衡。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。

负载均衡策略使用了轮询的方式，这是一种非常经典的负载均衡策略，该策略应用非常广泛。其原理很即是给每个请求标记一个序号，然后将请求依次派发到服务器节点中，适用于集群中各个节点提供服务能力等同且无状态的场景。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种多客户端的后台数据服务器***，其特征在于：包括服务器单元、和客户端单元，所述服务器单元包括数据中心，所述客户端单元包括若干个客户端子模块，所述客户端连接至服务器单元，所述数据中心包括缓存数据库和数据库集群，所述客户端子模块与所述服务器单元进行数据交换，所述服务器单元优先从缓存数据库中提取数据，如果缓存数据库中未提取到数据，则从数据库集群中查询提取，所述数据库集群根据服务器单元指令将数据同步至缓存数据库。

2.根据权利要求1所述的多客户端的后台数据服务器***，其特征在于：所述服务器单元还包括注册中心，服务中心，日志中心，文件服务器，所述注册中心通过客户端实现配置维护；所述服务中心实现定时任务服务；所述日志中心启动线程和客户端连接，所述文件服务器实现文件存储、文件同步和文件访问。

3.根据权利要求2所述的多客户端的后台数据服务器***，其特征在于：所述数据中心的数据库集群为Mysql数据库集群，为一主多从模式，包括一个master节点，多个slave节点。

4.根据权利要求2所述的多客户端的后台数据服务器***，其特征在于：所述注册中心为zookeeper分布式协调服务组件。

5.根据权利要求2所述的多客户端的后台数据服务器***，其特征在于：所述服务中心包括产品服务，商家服务，支付服务，圈子服务，设备服务，用户服务，所述服务中心dubbo对外提供服务。

6.根据权利要求2所述的多客户端的后台数据服务器***，其特征在于：所述日志中心为集中式日志***，包括Elasticsearch、Logstash、Kibana中的一种开源软件。

7.根据权利要求2所述的多客户端的后台数据服务器***，其特征在于：所述文件服务器为分布式文件***FastDFS。

8.根据权利要求1至7中任一项所述的多客户端的后台数据服务器***，其特征在于：所述客户端子模块包括终端APP、管理***模块、网站终端、商家终端中的一个或多个。

9.根据权利要求8所述的多客户端的后台数据服务器***，其特征在于：所述客户端子模块连接有用户终端交互设备。

10.一种如权利要求1至9中任一项所述的多客户端的后台数据服务器***的数据处理方法，其特征在于：包括如下步骤：

（1）客户端子模块与用户交互得到用户指令；

（2）客户端将指令发送至服务器单元；

（3）数据库集群根据指令进行数据同步至缓存数据库中；

（4）服务器单元从缓存数据库中提取数据；

（5）如果缓存数据提取失败，则从数据库集群中查询提取数据；

（6）服务器将数据返回至客户端；

（7）客户端将用户指令结果返回至用户终端。