背景 随着业务复杂程度的提高、数据规模的增长，越来越多的公司选择对其在线业务数据库进行垂直或水平拆分，甚至选择不同的数据库类型以满足其业务需求。原本在同一数据库实例里就能实现的SQL查询，现在需要跨多个数据库实例才能完成。业务的数据被“散落”在各个地方，如何方便地对这些数据进行汇总关联查询，已经成为困扰用户的一大难题。针对这类问题，传统的解决方案需要用户提前将所有实例的数据提前汇集到汇总库进行查询分析。这种方案不仅无法满足查询时效性，且用户还需要承担数据汇集的链路稳定性风险及数据冗余的经济成本。为了解决跨数据库实例及时查询的难题，阿里云DMS（数据管理）推出了跨数据库实例查询服务。 DMS跨数据库查询 跨实例查询服务支持通过标准SQL进行跨同异构数据库的实时查询。除了关系型数据库MySQL、SQLServer、PostgreSQL，还支持Redis。同时，跨实例查询服务还支持跨地域、跨云及线下IDC自建数据库及跨云厂商数据库实例间的数据实时查询，被广泛应用于多地域部署业务的全局数据查询场景。本文以MySQL及Redis为例，介绍如何通过一条SQL轻松完成跨数据库实例的查询。 通过标准SQL查询Redis 跨实例查询服务支持通过SQL查询Redis中的任意key，同时支持跨key之间的join查询。在进行SQL查询前，您需要先在跨实例查询服务中，创建Redis实例的DBLink。接下来简单介绍创建DBLink及进行SQL查询的流程。 创建DBLink 在跨实例查询服务的控制台，创建DBLink，配置Redis实例的连接信息。当完成DBLink创建后，需要使用这个DBLink编写查询SQL。 通过SQL查询Key 跨实例查询服务提供WEB SQL命令窗口，可以直接在命令窗口中，通过标准的SQL进行Key查询。具体支持的SQL命令可以参考使用文档。对于每一个redis的database， DMS会自动创建6张表，分别如下：all: 存储所有的keystring: 存储数据类型为string的可以hash：存储数据类型为hash的keylist: 存储数据类型为list的keyset：存储数据类型为set的keyzset：存储数据类型为score set的key每张表的表结构如下： 列名 类型 说明 Key Varchar Redis中的key名 Index Varchar 当数据类型为list/zset时，为各个元素的index;当数据类型为hash时，改字段为hash中的key名称 Value Varchar Key的value值 Score Double 表示SortedSet的分值，其他数据类型为null Expire_time Bigint 跟redis的ttl命令一致，表示数据离过期的剩余秒数 Data_type Varchar 这个key的数据类型 此处，我们通过通过如下的select语句查询all表中的前5个key。select * from redis_test.db0.all limit 5; 跨MySQL&Redis Join查询 日前接到某游戏客户跨MySQL及Redis查询的需求。该客户将用户积分排行榜存储在redis myzset中，而将用户元信息维护在MySQL user 表中。用户的某个简单诉求是：在游戏APP中能实时刷新用户的积分排行榜。 数据结构 通过redis score set存储用户积分情况，存储用户ID及score, key的名称为user_scrore， value为用户ID， score为用户积分。样例数据如下表： key value score user_score 100 10 user_score 200 35 user_score 300 45 通过MyQL User表存储用户的基本信息，包括user_id, user_name,province, city, gmt_create等，其中：User_id 为用户ID， User_name 为用户名Province 为用户所属省份， city 为用户所属市Gmt_create 为用户第一次登陆游戏APP的时间样例数据如下表： User_id User_name province city Gmt_create 100 张三 浙江 杭州 2018-11-11 11:11:11 200 李四 广东省 深圳 2018-10-11 12:11:01 关联查询 通过如下SQL，可方便得查询用户的积分排行榜。select user.user_name,zset.score from redis_test.db0.zset as zset join mysql.db0.user as user whereuser.user_id=zset.value and zset.key='user_score' order by zset.score desc; 这个SQL将redis中的用户ID跟MySQL中的user_id进行关联，且只查询存储用户积分的key。 小结 由于篇幅有限，本文只是简单介绍了DMS 跨数据库查询的功能及其在Redis上的使用案例。您可以立即体验跨数据库实例查询>>跨数据库查询的详细功能及使用场景可以参考：使用文档教你用一条SQL搞定跨数据库查询：如何玩转跨库Join

编辑推荐 ·涵盖Java EE主流框架技术SSM+Redis，快速上手开发·用Spring MVC整合MyBatis框架技术·用Spring整合Redis在Java互联网技术上的应用·通过秒杀、抢红包讲解互联网高并发业务 杨开振 周吉文 梁华辉 谭茂华 著 / 2017年7月出版 内容提要 随着移动互联网的兴起，以Java技术为后台的互联网技术占据了市场的主导地位，而在Java互联网后台开发中，SSM框架（Spring+Spring MVC+MyBatis）成为了主要架构，《Java EE互联网轻量级框架整合开发——SSM框架（Spring MVC+Spring+MyBatis）和Redis实现》以此为焦点从入门到实际工作要求讲述了SSM框架的技术应用；与此同时，为了提高系统性能，NoSQL（尤其是Redis）在互联网系统中已经广泛使用，为了适应这个变化，《Java EE互联网轻量级框架整合开发——SSM框架（Spring MVC+Spring+MyBatis）和Redis实现》通过Spring讲解了有关Redis的技术应用，这样更加贴近实际学习和工作的需要。 《Java EE互联网轻量级框架整合开发——SSM框架（Spring MVC+Spring+MyBatis）和Redis实现》主要分为6个部分，第1部分对Java互联网的框架和主要涉及的模式做初步简介；第2部分讲述MyBatis技术；第3部分讲述Spring基础（包括IoC、AOP和数据库应用），重点讲解Spring数据库事务应用，以满足互联网企业的应用要求；第4部分，讲述Spring MVC框架；第5部分，通过Spring技术的应用，讲解Redis技术；第6部分，讲解SSM+Redis实践应用，通过互联网高并发如抢票、抢红包等场景，使用全注解的方式讲解SSM框架的整合，以及高并发与锁的应用和系统性能优化。 《Java EE互联网轻量级框架整合开发——SSM框架（Spring MVC+Spring+MyBatis）和Redis实现》结合企业的实际需求，从原理到实践全面讲解SSM+Redis技术应用，无论你是Java程序员、SSM应用和研究人员，还是Redis应用人员、互联网开发人员，都可以从《Java EE互联网轻量级框架整合开发——SSM框架（Spring MVC+Spring+MyBatis）和Redis实现》中收获知识。 作者简介 -杨开振 拥有十余年一线Java开发工作经验，热衷于Java互联网技术方向研究，目前从事Java互联网技术在线教育，著有畅销书《深入浅出MyBatis技术原理与实战》。 -周吉文 高级工程师，曾获广东省科技进步一等奖，曾任国家“863”计划项目软件组组长，担任珠海市第二人民医院信息部主任多年，有丰富的项目实施和管理经验。 -梁华辉 资深Java开发专家，有丰富的企业级应用及Web项目的开发经验。对软件设计模式和代码整洁方面有深入理解，对Spring、Hibernate等主流开源框架有深入研究。 -谭茂华 资深Java开发专家，拥有十余年供应链管理、金融、物联网等行业大型系统软件开发经验。热衷于软件架构、软件研发过程控制、Java开源技术（尤其是Spring体系技术）的研究。 媒体评论 本书从基础理论讲起，菜鸟可以由此登堂入室，功力再上一层楼。结合源码分析，深入浅出，轻松一窥底层原理，适合大侠修炼内功。书中案例非常切合互联网应用的实际，对架构设计有很好的借鉴和参考意义。 ——前华为架构师、腾讯高级工程师 代继红 高速数据流和高并发访问是目前互联网应用数据处理层面临的严峻挑战。本书对互联网时代业界流行的“SSM+Redis”的Java互联网技术进行了详细介绍，给需要搭建高效互联网应用的企业或个人提供了应对挑战的利器。本书内容由浅入深，逻辑清晰，代码丰富，可操作性强，是一本既适合新手入门又适合高手修炼的技术宝典。 ——广西大学教授 许嘉 本书通过精要的描述、清晰的图示和恰当的示例，由浅入深阐述当前最流行的Java EE互联网框架技术原理和应用，是学习Java互联网技术应用难得一见的好书。 ——《Qt Quick核心编程》作者、订阅号“程序视界”创建者 安晓辉 图书试读 前言 随着移动互联网的兴起以及手机和平板电脑的普及，Java开发方向发生了很大变化，渐渐从管理系统走向了互联网系统。互联网系统的要求是大数据、高并发、高响应，而非管理系统的少数据、低并发和缓慢响应。为顺应技术发展趋势，2016年春季笔者写了一本关于MyBatis的著作《深入浅出MyBatis技术原理与实战》，作为国内第一本关于MyBatis技术的著作，该书受到了业内的广泛肯定。与此同时，电子工业出版社编辑汪达文给了我一个很好的建议，她建议写一本Java合集，这更贴近开发工作的实际需求。在移动互联网兴起的时代，Spring+Spring MVC+MyBatis（SSM）的Java组合已经成为时代的主流，伴随着NoSQL（缓存）的广泛应用，Redis成了主要的NoSQL工具，这些都是当今移动互联网最为流行的技术，于是笔者打算竭尽所能写一本SSM+Redis的合集，这就是本书创作的缘起。 移动互联网的新要求 高并发：举个例子，大公司企业ERP应用，有1万名员工使用，同时在线的用户可能只有数百人，而操作一个业务的同一个数据的可能只有几个人，其系统一般不会存在高并发的压力，使用传统程序和数据库完全可以应付。在互联网中一件热门的商品，比如新版小米手机，可能刚一上市就有成千上万的请求到达服务器，要求瞬间执行数以万计的数据操作，对性能要求高，操作不当容易造成网站瘫痪，引发网站的生存危机。 高响应：企业管理系统可以缓慢处理一些业务，而在高并发的互联网系统中，却不可以，按照互联网的要求一般以5秒为上限，超过5秒后响应，用户体验不好，从而影响用户忠诚度，而这些往往需要在高并发和大数据量的场景下实现。 数据一致性：由于高并发，多个线程对同一数据同时访问，需要保证数据的一致性，比如电商网站的金额、商品库存不能出错，还要保证其性能不能太差，这是在管理系统中不会出现的场景。技术复杂化：在互联网中流行许多新技术，比如常见的NoSQL（Redis、MongoDB），又如MQ、RPC框架、ZooKeeper、大数据、分布式等技术。 为什么选择SSM框架+Redis的开发模式 首先，Struts2框架和Spring结合，多年来改变不了臃肿的老毛病，更为严重的是近年来多次出现的漏洞问题，使得其名声和使用率大降。这个时候Spring MVC框架成了新一代MVC框架的主流。它原生于Spring框架，可以无缝对接Spring的核心技术。与Struts不同，它的流程模块化，没有那么多臃肿的类，所以互联网应用的框架大部分使用的是Spring MVC。 其次，目前企业的Java应用中，Spring框架是必须的，Spring的核心是IoC（控制反转），它是一个大容器，方便组装和管理各类系统内外部资源，同时支持AOP（面向切面编程），这是对面向对象的补充，目前广泛用于日志和数据库事务控制，减少了大量的重复代码，使得程序更为清晰。因为Spring可以使模块解耦，控制对象之间的协作，所以Spring框架是目前Java最为流行的框架，几乎没有之一。 最后，对于Hibernate而言，笔者感慨最多，在需要存储过程或者复杂SQL时，它的映射关系几乎完全用不上，所有的问题都需要自己敲代码处理。作为全映射的框架，它的致命缺点是没有办法完全掌控数据库的SQL，而优化SQL是高并发、高响应系统的必然要求，这是互联网系统的普遍特性，所以Hibernate在互联网系统中被排除了。而另一个持久层框架MyBatis，它需要编写SQL、提供映射规则，不过它加入了动态SQL、自动映射、接口编程等功能使得它简单易用，同时支持SQL优化、动态绑定，并满足高并发和高响应的要求，所以它成为最流行的Java互联网持久框架。 NoSQL的成功在于，首先它是基于内存的，也就是数据放在内存中，而不是像数据库那样把数据放在磁盘上，而内存的读取速度是磁盘读取速度的几十倍到上百倍，所以NoSQL工具的速度远比数据库读取速度要快得多，满足了高响应的要求。即使NoSQL将数据放在磁盘中，它也是一种半结构化的数据格式，读取到解析的复杂度远比数据库要简单，这是因为数据库存储的是经过结构化、多范式等有复杂规则的数据，还原为内存结构的速度较慢。NoSQL在很大程度上满足了高并发、快速读/写和响应的要求，所以它也是Java互联网系统的利器。于是两种NoSQL的工具Redis和MongoDB流行起来，尤其是Redis已经成为了主要的NoSQL工具，本书会详细介绍它的常用方法。 基于以上原因，Spring+Spring MVC +MyBatis已经成了Java互联网时代的主流框架，而Redis缓存已经成了主流的NoSQL技术，笔者愿意将自己所掌握的知识分享给大家，为目前奋斗在SSM和Redis战线上的同行们奉献一本有价值的参考书，给一些准备进入这个行业的新手一定的帮助和指导。 积跬步以至千里。每天读本书，为您搜罗最具权威专业书籍，更多图书推荐请关注每日读书。 好知识需要分享，如您有喜欢的书籍想与广大开发者分享，请在文章下方评论留言，我们将为大家推荐您的爱书！

基于 python 分布式房源数据抓取系统为数据的进一步应用即房源推荐系统做数据支持。本课题致力于解决单进程单机爬虫的瓶颈，打造一个基于 Redis 分布式多爬虫共享队列的主题爬虫。本系统采用 python 开发的 Scrapy 框架来开发，使用 Xpath 技术对下载的网页进行提取解析，运用 Redis 数据库做分布式，使用MongoDb 数据库做数据存储，利用 Django web 框架和 Semantic UI开源框架对数据进行友好可视化，最后使用了Docker对爬虫程序进行部署。设计并实现了针对 58 同城各大城市租房平台的分布式爬虫系统。 分布式爬虫抓取系统主要包含以下功能： 1．爬虫功能： 爬取策略的设计 内容数据字段的设计 增量爬取 请求去重 2．中间件： 爬虫防屏蔽中间件 网页非200状态处理 爬虫下载异常处理 3．数据存储： 抓取字段设计 数据存储 4．数据可视化 完整项目源码 关注微信公众号 datayx 然后回复 分布式 即可获取。 二、系统分布式架构 分布式采用主从结构设置一个Master服务器和多个Slave服务器，Master端管理Redis数据库和分发下载任务，Slave部署Scrapy爬虫提取网页和解析提取数据，最后将解析的数据存储在同一个MongoDb数据库中。分布式爬虫架构如图所示。 应用Redis数据库实现分布式抓取，基本思想是Scrapy爬虫获取的到的detail_request的urls都放到Redis Queue中，所有爬虫也都从指定的Redis Queue中获取requests，Scrapy-Redis组件中默认使用SpiderPriorityQueue来确定url的先后次序，这是由sorted set实现的一种非FIFO、LIFO方式。因此，待爬队列的共享是爬虫可以部署在其他服务器上完成同一个爬取任务的一个关键点。此外，在本文中，为了解决Scrapy单机局限的问题，Scrapy将结合Scrapy-Redis组件进行开发，Scrapy-Redis总体思路就是这个工程通过重写Scrapu框架中的scheduler和spider类，实现了调度、spider启动和redis的交互。实现新的dupefilter和queue类，达到了判重和调度容器和redis的交互，因为每个主机上的爬虫进程都访问同一个redis数据库，所以调度和判重都统一进行统一管理，达到了分布式爬虫的目的。 三、系统实现 1）爬取策略的设计 由scrapy的结构分析可知，网络爬虫从初始地址开始，根据spider中定义的目标地址获的正则表达式或者Xpath获得更多的网页链接，并加入到待下载队列当中，进行去重和排序之后，等待调度器的调度。 在这个系统中，新的链接可以分为两类，一类是目录页链接，也就是我们通常看到的下一页的链接，一类是内容详情页链接，也就是我们需要解析网页提取字段的链接，指向的就是实际的房源信息页面。网络需从每一个目录页链接当中，提取到多个内容页链接，加入到待下载队列准备进一步爬取。 此处是Master端的目标链接的爬取策略，因为采取的分布式主从模式，Master端爬虫主要爬取下载到内容详情页链接，通过redis分享下载任务给其他slave端的爬虫。Slave端主要是负责对详情页链接的进一步解析提取存储到数据库中。 本论文以58同城租房为例，其初始页链接，其实也就是每个分类的第一页链接，主要有(以广东省几个城市为例): 综上所述，网络房源爬取系统使用以下爬取策略: 1) 对于Master端: 最核心模块是解决翻页问题和获取每一页内容详情页链接。 Master端主要采取以下爬取策略： 1. 向redis往key为nest_link插入初始链接，从初始页链接开始 2. 爬虫从redis中key为next_link中取到初始链接，开始运行爬虫 3. 将下载器返回的Response,爬虫根据spider定义的爬取规则识别是否有下一页链接，若有链接，存储进redis中，保存key为next_link，同时根据匹配规则是否匹配到多个内容详情页链接，若匹配到，则存储进Redis,保存key为detail_request插入下载链接，给slave端的spider使用，即是Slave端的下载任务。 4. 爬虫继续从redis中key为next_link取值，若有值，继续步骤2，若为空，爬虫则等待新的链接。 2) 对于Slave端: 最核心模块是从redis获得下载任务，解析提取字段。Slave端主要采取以下爬取策略: 1．爬虫从redis中key为detail_request中取到初始链接，开始运行爬虫 2．将下载器返回的Response,爬虫根据spider定义的爬取规则识别是否有匹配规则的内容字段，若有将字段存储，返回到模型中，等待数据存储操作。 重复步骤1，直到带爬取队列为空，爬虫则等待新的链接。 2）爬虫的具体实现 爬虫程序的包含四个部分，分别是对象定义程序，数据抓取程序，数据处理程序和下载设置程序，此处的组成是Slave端，Master少了对象定义程序以及数据处理程序，Master端主要是下载链接的爬取。 （1）数据抓取程序 数据抓取程序分Master端和Slave端，数据抓取程序从Redis中获得初始地址，数据抓取程序中定义了抓取网页的规则和使用Xpath提取字段数据的方法等，这里着重介绍Xpath提取字符数据的方法，Xapth使用路径表达式来选取网页文档中的节点或者节点集。在Xpath中有其中类型的几点:元素、属性、文本、命名空间、处理指令、注释和文档节点。网页文档是被当做节点树来对待，树的跟被称为文档节点和根节点，通过Xpath表达式定位目标节点即可抽取网页文档的字段数据。 3）去重与增量爬取 去重与增量爬取，对于服务器有很重大的意义，能够减少服务器的压力以及保证数据的准确性。如果不采取去重处理，那么抓取的内容会抓取大量重复内容，让爬虫效率极大的下降。其实去重流程很简单，核心就是每次请求的时候，先判断这个请求是否在已经爬取的队列当中。如果已存在，则舍弃当前请求。 具体实现步骤:  (1) 从待爬队列中获取url （2) 将即将请求的url判断是否已经爬取，若已爬取，则将请求忽略，未爬取，继续其他操作并将url插入已爬取队列中 （3) 重复步骤1 这里我们使用scrapy-redis的去重组件，所以也没有实现，不过原理还是要看懂的，具体可以看源码。 4）爬虫中间件 爬虫中间件能够帮助我们在scrapy抓取流程中自由的扩展自己的程序，以下有爬虫防屏蔽中间件，下载器异常状态中间件以及非200状态中间件。 （1）爬虫防屏蔽组件的实现 访问一个网站的网页的时候，会给网站带了一定的负载，而爬虫程序则是模拟了我们正常访问网页的过程，但是。大规模的爬虫会给网站增加大量的负载，影响正常用户的访问。为保证网页能够别大多数正常用户的访问，大多数网站都有相应的防爬虫策略。一旦访问行为被认定为爬虫，网站将会采取一定的措施，限制你的访问，比如提示你，访问过于频繁让你输入验证码，更严重者，会封掉你的ip，禁止你访问该网站。本系统定向抓取网页数据的时候，将不间断的访问网站内容，如果不采取伪装措施，很容易被网站识别为爬虫行为而屏蔽掉。 本系统采用以下方法来防止爬虫被屏蔽: （a）模拟不同浏览器行为实现思路及代码 原理: 从scrapy的介绍我们可以知道，scrapy有下载中间件，在这个中间件我们可以对请求跟响应进行自定义处理，类似于spring面向切面编程，像一个钩子嵌入到程序的运行前后。核心就是对请求的属性进行修改 首先主要是对下载中间件进行了扩展，首先在seetings.py上面增加中间件， 其次，扩展中间件，主要是写一个useragent列表，将常用的浏览器请求头保存为一个列表. 再让请求的头文件随机在列表中取一个agent值，然后到下载器进行下载。 综上，每次发出请求的时候模拟使用不同的浏览器对目标网站进行访问。 （b）使用代理ip进行爬取的实现思路及代码。 首先在seetings.py上面增加中间件，扩展下载组件请求的头文件随机从代理ip池中取出一个代理值然后到下载器进行下载。 1. 代理ip池的设计与开发流程如下: a. 对免费代理ip网站进行抓取。 b. 对代理ip进行存储并验证 c. 验证通过存储进数据库 d. 如果满足ip最大数量，则停止爬去，一定时间后验证数据的ip有效性，将失效的ip删除 e. 直到数据库ip小于0，继续爬取ip，重复步骤a。 代理ip爬虫运行截图: （c）爬虫异常状态组件的处理 爬虫没有被屏蔽运行时，访问网站不是一直都是200请求成功，而是有各种各样的状态，像上述爬虫被禁的时候，其实返回的状态是302，防止屏蔽组件就是捕捉到302状态加以实现的。同时异常状态的处理有利于爬虫的健壮性。 在settings中扩展中间件捕捉到异常的情况之后，将请求Request重新加入到待下载队列当中流程如下: d）数据存储模块 数据存储模块主要负责将slave端爬取解析的页面进行存储。使用Mongodb对数据进行存储。 Scrapy支持数据存储的格式有json，csv和xml等文本格式，用户可以在运行爬虫时设置，例如:scrapy crawl spider -o items.json -t json,也可以在Scrapy工程文件额ItemPipline文件中定义，同时，Scrapy也支持数据库存储，如Monogdb，Redis等，当数据量大到一定程度时，可以做Mongodb或者Reids的集群来解决问题，本系统数据存储如下图所示: （g）数据可视化设计 数据的可视化其实也就是，将数据库的数据转换成我们用户容易观察的形式，本系统使用Mongodb对数据进行存储。对数据进行可视化基于Django+Semantiui,效果如下图所示: 四、系统部署 因为分布式部署所需环境都是类似的，如果一个服务器部署程序都需要在配置下环境显得很麻烦，这里使用了docker镜像对爬虫程序进行部署，使用了Daocloud上的scrapy-env对程序进行了部署 。系统以58同城租房平台为抓取目标，运行十小时之后，持续抓取网页数量共计几万条房源数据。 原文发布时间为：2018-09-22 本文来自云栖社区合作伙伴“大数据挖掘DT机器学习”，了解相关信息可以关注“大数据挖掘DT机器学习”。

在12月的云栖大会广东分会上，阿里云宣布了2016年以来第18次降价。 数据产品降价更超过30%，平均降幅20%，最高降幅52.9%，本次降价涉及到的产品有ApsaraDB for MySQL，Redis， SQL Server，MongoDB， PostgreSQL，PPAS等产品。     数据库作为底层的数据存储和管理工具，是云计算生态系统中的重要一环，随着"大数据时代"的到来，在高并发、大数据量、分布式以及实时性的要求之下，阿里云的数据库产品能够充分的满足客户需求。 阿里云的数据库产品覆盖了包括MySQL、Redis等开源数据库在内的70%的市场主流关键数据库在线引擎，数据在一个体系内流转和解决后期所有的分析问题。同时，ApsaraDB基于飞天操作系统和全SSD盘高性能存储，性能指标全面领跑。也是国内首个通过国家“等保三级”安全标准的数据库，ApsaraDB在网络层支持专有网络(VPC)，隔离了外部网络环境；而在数据加密上又有SSL、TDE双重加密功能双保险，从根本上保障您的数据安全。 本次降价将给客户带来巨大的普惠红利价值，以国内某视频网站为例，该网站使用阿里云8核32G的MySQL产品，本次降价以后，每年的数据库成本降低了22.6%，这对于海量访问的网站来说，节约了可观的成本。 而国内另一个知名的直播平台使用了阿里云16G的redis产品，在本次降价以后，每年节约了数十万的数据库购买成本。 不仅如此，阿里云数据库有效的帮助客户提升了业务效率：天弘基金余额宝将原有Oracle数据拆分成多个RDS实例，通过高并发集群计算能力，收益清算时间从24小时缩短到4小时。 污染地图APP，经过专家服务定制性优化，查询效率提升50%以上，搭配RDS配置弹性升级，顶住了几十倍的业务压力。 降价的背后，是阿里云的技术创新带来的红利， 在11月的Sort Benchmark上，阿里云以$1.44/TB的成绩夺冠，打破了AWS在2014年保持的纪录4.51$/TB，平均每TB的计算成本下降了68%，阿里云通过自身的技术努力，降低了云计算的成本。 而这样的红利，又融入业务场景之中，继续推动成本的降低：越来越多的像双11这样的脉冲场景出现，这样的脉冲场景，让公共资源池的体量更大，价格更加普惠。 阿里云资深总监李津告诉记者，阿里云不怕打价格战，因为价格的降低，将倒逼各个云计算厂商去推动技术的进步，让技术的红利更充分释放给客户，云计算市场将更加普及和激活，更多在IT建设上捉襟见肘的中小企业，将通过云计算获得与大型企业同样的技术支撑，从而可以将精力更多地投入到业务创新中来。 “合理的价格，将加速中国云计算市场的进化，给客户带来真正的价值。”阿里云资深专家何云飞表示。 根据阿里最新财报显示，云计算业务营收达12.43亿元，同比增长156%，已经成为继亚马逊AWS、微软Azure之后的全球第三大云计算服务商。

背景 数据管理DMS企业版提供了安全、高效地管理大规模数据库的服务。面对多元的数据库实例，为了更方便地查询被“散落”在各个地方的业务数据，我们在DMS企业版中提供了跨数据库实例查询服务。 什么是跨实例查询 跨实例查询服务支持通过标准SQL进行跨同异构数据库的实时查询。对于您在企业版中的实例，无论它们是关系型数据库MySQL、PolarDB、DRDS、SQLServer、PostgreSQL，还是非关系型数据库Redis，您都可以通过一条SQL轻松完成跨数据库实例的查询。 如何进行跨实例查询 每当您在企业版中注册一个跨库查询支持的实例，系统就将自动为其创建DBLink，您可以为其命名。您可以将DBLink名称认为是该数据库实例的别名。对于您在企业版中已有的实例或者您批量导入的实例，系统将自动为其命名，您后续可以对该名字进行修改。有了DBLink名称，您就可以用DBLink名称指代您希望进行查询的实例。通过DBLinkName.DatabaseName.TableName的格式，您就可以进行跨库查询操作了。 应用案例 案例1 垂直拆分后的跨数据库查询 DMS企业版的用户某电商公司由于业务发展迅猛，访问量极速增长，导致数据库容量及性能遭遇瓶颈，因此用户决定将会员、商品、订单数据分别存放在三个数据库实例中。用户将订单库所在的实例A取名为buyer_db，订单所在的库为buyer，订单表为order_list，将商品库所在的实例B取名为seller_db，商品所在的库为commodity，商品表为commodity。此时，公司的数据分析人员想要获取某个品类商品的实时售卖订单量，需要变成跨两个数据库实例A和B的查询，怎么办？有了跨库查询，无需数据迁移、数据汇集、ETL，即可直接完成多个在线数据库之间的关联查询。一条SQL，用户即可解决上述难题: 案例2 水平拆分后的跨数据库查询 DMS企业版的用户某酒店在多个城市都有对应的门店，其数据库在每个城市也会单独部署一套，业务上有对多个城市全局数据查询的诉求。同样，现在越来越多的互联网行业开始引入单元化架构，在每个城市会单独部署机房和数据库，进行多单元数据汇总查询的需求也越来越强。为了满足云上这些跨单元、跨region的数据库查询需求，跨库查询服务打通region之间的屏障，用户通过一条SQL就能实现这些需求。 案例3 异构数据库的关联查询 DMS企业版的用户某公司考虑成本和未来可扩展性，正在将业务数据从SQLServer迁移到MySQL上。在这期间，必然存在某些业务子系统仍然在SQLServer上，另外一些业务子系统已经全部迁移到MySQL上，这时两个子系统之间的联合查询，就可以借助跨库查询实现。不仅如此，在迁移过程中，还可以通过DSQL，来校验SQLServer和MySQL上的数据是否一致。 案例4 混合云场景的关联查询 DMS企业版的用户某游戏公司，由于各种原因，在DMS企业版中同时保有阿里云、腾讯、UCloud、AWS等环境的数据库实例，同时在自己自建的IDC也部署了部分数据库。业务的数据如此分散，单是统计一下当前游戏在线用户数，都要分别到各个环境去查询一遍再做汇总。借助跨库查询服务，一条SQL就能实现跨云厂商和IDC之间的关联查询。 案例5 关系型与非关系型数据库的关联查询 DMS企业版的用户某游戏客户将用户积分排行榜存储在redis zset中，而将用户元信息维护在MySQL user表中。用户希望在游戏APP中能实时刷新用户的积分排行榜，通过跨库查询服务，就可以实现跨MySQL及Redis查询的需求。用户在Redis Score Set中存储用户积分情况、用户ID及score。key的名称为user_score， value为用户ID， score为用户积分。样例数据如下表： key value score user_score 100 10 user_score 200 35 user_score 300 45 用户在MySQL User表中存储用户的基本信息，包括user_id, user_name, province, city, gmt_create等。样例数据如下表： user_id user_name province city gmt_create 100 张三 浙江 杭州 2019-8-11 11:11:11 200 李四 广东 深圳 2019-7-11 12:11:01 用户只需要一条SQL，将redis中的用户ID跟MySQL中的user_id进行关联，就可以方便地查询用户的积分排行榜。 小结 跨库查询服务为您提供了您在DMS企业版中的多个实例之间的关联查询。详细使用文档您可以参考：使用文档 戳这里了解更多>>>数据管理DMS

背景 数据管理DMS企业版提供了安全、高效地管理大规模数据库的服务。面对多元的数据库实例，为了更方便地查询被“散落”在各个地方的业务数据，我们在DMS企业版中提供了跨数据库实例查询服务。 什么是跨实例查询 跨实例查询服务支持通过标准SQL进行跨同异构数据库的实时查询。对于您在企业版中的实例，无论它们是关系型数据库MySQL、PolarDB、DRDS、SQLServer、PostgreSQL，还是非关系型数据库Redis，您都可以通过一条SQL轻松完成跨数据库实例的查询。 如何进行跨实例查询 每当您在企业版中注册一个跨库查询支持的实例，系统就将自动为其创建DBLink，您可以为其命名。您可以将DBLink名称认为是该数据库实例的别名。对于您在企业版中已有的实例或者您批量导入的实例，系统将自动为其命名，您后续可以对该名字进行修改。有了DBLink名称，您就可以用DBLink名称指代您希望进行查询的实例。通过DBLinkName.DatabaseName.TableName的格式，您就可以进行跨库查询操作了。 应用案例 案例1 垂直拆分后的跨数据库查询 DMS企业版的用户某电商公司由于业务发展迅猛，访问量极速增长，导致数据库容量及性能遭遇瓶颈，因此用户决定将会员、商品、订单数据分别存放在三个数据库实例中。用户将订单库所在的实例A取名为buyer_db，订单所在的库为buyer，订单表为order_list，将商品库所在的实例B取名为seller_db，商品所在的库为commodity，商品表为commodity。此时，公司的数据分析人员想要获取某个品类商品的实时售卖订单量，需要变成跨两个数据库实例A和B的查询，怎么办？有了跨库查询，无需数据迁移、数据汇集、ETL，即可直接完成多个在线数据库之间的关联查询。一条SQL，用户即可解决上述难题: 案例2 水平拆分后的跨数据库查询 DMS企业版的用户某酒店在多个城市都有对应的门店，其数据库在每个城市也会单独部署一套，业务上有对多个城市全局数据查询的诉求。同样，现在越来越多的互联网行业开始引入单元化架构，在每个城市会单独部署机房和数据库，进行多单元数据汇总查询的需求也越来越强。为了满足云上这些跨单元、跨region的数据库查询需求，跨库查询服务打通region之间的屏障，用户通过一条SQL就能实现这些需求。 案例3 异构数据库的关联查询 DMS企业版的用户某公司考虑成本和未来可扩展性，正在将业务数据从SQLServer迁移到MySQL上。在这期间，必然存在某些业务子系统仍然在SQLServer上，另外一些业务子系统已经全部迁移到MySQL上，这时两个子系统之间的联合查询，就可以借助跨库查询实现。不仅如此，在迁移过程中，还可以通过DSQL，来校验SQLServer和MySQL上的数据是否一致。 案例4 混合云场景的关联查询 DMS企业版的用户某游戏公司，由于各种原因，在DMS企业版中同时保有阿里云、腾讯、UCloud、AWS等环境的数据库实例，同时在自己自建的IDC也部署了部分数据库。业务的数据如此分散，单是统计一下当前游戏在线用户数，都要分别到各个环境去查询一遍再做汇总。借助跨库查询服务，一条SQL就能实现跨云厂商和IDC之间的关联查询。 案例5 关系型与非关系型数据库的关联查询 DMS企业版的用户某游戏客户将用户积分排行榜存储在redis zset中，而将用户元信息维护在MySQL user表中。用户希望在游戏APP中能实时刷新用户的积分排行榜，通过跨库查询服务，就可以实现跨MySQL及Redis查询的需求。用户在Redis Score Set中存储用户积分情况、用户ID及score。key的名称为user_score， value为用户ID， score为用户积分。样例数据如下表： key value score user_score 100 10 user_score 200 35 user_score 300 45 用户在MySQL User表中存储用户的基本信息，包括user_id, user_name, province, city, gmt_create等。样例数据如下表： user_id user_name province city gmt_create 100 张三 浙江 杭州 2019-8-11 11:11:11 200 李四 广东 深圳 2019-7-11 12:11:01 用户只需要一条SQL，将redis中的用户ID跟MySQL中的user_id进行关联，就可以方便地查询用户的积分排行榜。 小结 跨库查询服务为您提供了您在DMS企业版中的多个实例之间的关联查询。详细使用文档您可以参考：使用文档 戳这里了解更多>>>数据管理DMS

sorted_set 类型新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式需要的存储结构：新的存储模型，可以保存可排序的数据sorted_set类型：在set的存储结构基础上添加可排序字段sorted_set 类型数据的基本操作添加数据 zadd key score1 member1 [score2 member2]获取全部数据数据 zrange key start stop [WITHSCORES] # 递增排列 zrevrange key start stop [WITHSCORES] # 递减排列删除数据 zrem key member [member ...]按条件获取数据 zrangebyscore key min max [WITHSCORES] [LIMIT] zrevrangebyscore key max min [WITHSCORES]从小到大排列从大到小排列条件删除数据zremrangebyrank key start stop zremrangebyscore key min max注意：min与max用于限定搜索查询的条件start与stop用于限定查询范围，作用于索引，表示开始和结束索引offset与count用于限定查询范围，作用于查询结果，表示开始位置和数据总量获取集合数据总数量zcard key zcount key min max获取0-50的数量zcard key zcount key min max集合交、并操作zinterstore destination numkeys key [key ...] zunionstore destination numkeys key [key ...]sorted_set 类型数据的扩展操作业务场景票选广东十大杰出青年，各类综艺选秀海选投票各类资源网站TOP10（电影，歌曲，文档，电商，游戏等）聊天室活跃度统计游戏好友亲密度业务分析为所有参与排名的资源建立排序依据解决方案：获取数据对应的索引（排名）添加相关基础数据zadd movies 143 aa 97 bb 201 cczrank key member zrevrank key member   score值获取与修改zscore key member zincrby key increment memberredis 应用于计数器组合排序功能对应的排名sorted_set 类型数据操作的注意事项score保存的数据存储空间是64位，如果是整数范围是-9007199254740992~9007199254740992score保存的数据也可以是一个双精度的double值，基于双精度浮点数的特征，可能会丢失精度，使用时候要慎重sorted_set 底层存储还是基于set结构的，因此数据不能重复，如果重复添加相同的数据，score值将被反复覆盖，保留最后一次修改的结果sorted_set 类型应用场景业务场景基础服务+增值服务类网站会设定各位会员的试用，让用户充分体验会员优势。例如观影试用VIP、游戏VIP体验、云盘下载体验VIP、数据查看体验VIP。当VIP体验到期后，如果有效管理此类信息。即便对于正式VIP用户也存在对应的管理方式。 网站会定期开启投票、讨论，限时进行，逾期作废。如何有效管理此类过期信息。解决方案对于基于时间线限定的任务处理，将处理时间记录为score值，利用排序功能区分处理的先后顺序记录下一个要处理的时间，当到期后处理对应任务，移除redis中的记录，并记录下一个要处理的时间当新任务加入时，判定并更新当前下一个要处理的任务时间为提升sorted_set的性能，通常将任务根据特征存储成若干个sorted_set。例如1小时内，1天内，周内，月内，季内，年度等，操作时逐级提升，将即将操作的若干个任务纳入到1小时内处理的队列中time获取当前系统时间redis 应用于定时任务执行顺序管理或任务过期管理业务场景任务/消息权重设定应用 当任务或者消息待处理，形成了任务队列或消息队列时，对于高优先级的任务要保障对其优先处理，如何实现任务权重管理。解决方案对于带有权重的任务，优先处理权重高的任务，采用score记录权重即可多条件任务权重设定如果权重条件过多时，需要对排序score值进行处理，保障score值能够兼容2条件或者多条件，例如外贸订单优先于国内订单，总裁订单优先于员工订单，经理订单优先于员工订单因score长度受限，需要对数据进行截断处理，尤其是时间设置为小时或分钟级即可（折算后）先设定订单类别，后设定订单发起角色类别，整体score长度必须是统一的，不足位补0。第一排序规则首位不得是0例如外贸101，国内102，经理004，员工008。员工下的外贸单score值为101008（优先）经理下的国内单score值为102004redis 应用于即时任务/消息队列执行管理

12月15日的云栖大会 · 广东分会上，阿里云宣布推出“免费套餐”计划，获得邀请码的新用户可在半年内免费使用30余款云产品，目前开放的产品类型包括弹性计算、数据库、中间件、安全、云市场等。阿里云表示，希望通过这一计划加速普及云计算技术。 在阿里云官网上"免费套餐"已有13个大类，共计34款产品。包括了阿里云已有100余款产品中的主流产品，如云服务器ECS、容器服务、对象存储OSS、云数据库RDS、Redis、MongoDB、安骑士、态势感知、证书服务、.xin域名、企业邮箱等。新用户通过这些入门级的产品与服务，可以快速熟悉云计算的产品与操作，以适合自己的方式组合使用。 阿里云产品负责人何云飞表示，“我们要做的就是不断降低门槛，推动云计算这一普惠科技的普及，为中小创业企业和工程师群体带来帮助。 ‘免费套餐’计划将根据进展继续扩大产品覆盖范围。” 两个月前，阿里云宣布中国区云产品全线降价，核心云产品最高降幅达50%，并推出三年五折的价格政策。

写这篇文章是为了分享一下我最近使用ECS的体验，我是广东的云计算专业的一名学生。暑期期间想要学习一些新的知识，比如redis，docker等，如果使用虚拟机的话会很麻烦，使用服务器的话，会方便很多。然后我的同学就给我推荐了阿里云的服务器，说学生用户可以免费试用。我就登陆了阿里云通过了学生认证，做完了实验教程和基础阶段测试就领取到了14天的ECS服务器体验版。在领取后，可以得到一个链接，并且自己设置了一个密码，之后就会拥有自己的服务器，可以在上面部署自己的项目。在安装好了环境之后，通过相关的模板能够方便的使用自己的服务器。虽然使用过程中也碰到了许多的问题，但是由于是使用的阿里的服务器，所以社区讨论度很高，在网上社区询问一些大佬也能够找到最后的解决方法，用起来就很舒服。使用阿里云非常省心。不需要去管服务器硬件，阿里的技术也非常的牛，很稳定，不存在自己使用虚拟机时的一些问题。阿里云的服务器非常安全，不会出现安全问题。能够给我们资金匮乏的学生一个通过服务器学习的机会，感谢阿里让我们能够体验免费的使用服务器。在使用的这几天里，体验还是非常好的。假如以后能够有机会，我自己也会去阿里买一个自己的服务器。十分感谢阿里免费赠送的服务器体验，我也会好好珍惜这段时间，希望我自己能够利用这段时间好好的提升自己。

当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。 Web负载均衡 Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。 负载均衡的策略有很多，我们从简单的讲起哈。 1. HTTP重定向 当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302，如下图： 亿级Web系统搭建——单机到分布式集群 – hansionxu – 技术的天空 如果使用PHP代码来实现这个功能，方式如下： 这个重定向非常容易实现，并且可以自定义各种策略。但是，它在大规模访问量下，性能不佳。而且，给用户的体验也不好，实际请求发生重定向，增加了网络延时。 2. 反向代理负载均衡 反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。 Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。 解决方案主要有两种： 配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。 将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。 反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。 3. IP负载均衡 IP负载均衡服务是工作在网络层（修改IP）和传输层（修改端口，第四层），比起工作在应用层（第七层）性能要高出非常多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），通过IPVS（IP Virtual Server，IP虚拟服务）来实现。 在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，然后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。 上述的方式叫LVS-NAT，除此之外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，但是有一定的区别，篇幅问题，不赘叙。 IP负载均衡的性能要高出Nginx的反向代理很多，它只处理到传输层为止的数据包，并不做进一步的组包，然后直接转发给实际服务器。不过，它的配置和搭建比较复杂。 4. DNS负载均衡 DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。 这种负载均衡策略，配置简单，性能极佳。但是，不能自由定义规则，而且，变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。 5. DNS/GSLB负载均衡 我们常用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，通过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。一般情况下都是按照地理位置，将离用户近的IP返回给用户，减少网络传输中的路由节点之间的跳跃消耗。 图中的“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），然后得到指定域名的授权DNS，然后再获得实际服务器IP。 CDN在Web系统中，一般情况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽可能离用户更近，提升用户体验。 例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的原因是防止http请求的时候，带上了多余的cookie信息），我获得的IP是183.60.217.90。 这种方式，和前面的DNS负载均衡一样，不仅性能极佳，而且支持配置多种策略。但是，搭建和维护成本非常高。互联网一线公司，会自建CDN服务，中小型公司一般使用第三方提供的CDN。 Web系统的缓存机制的建立和优化 刚刚我们讲完了Web系统的外部网络环境，现在我们开始关注我们Web系统自身的性能问题。我们的Web站点随着访问量的上升，会遇到很多的挑战，解决这些问题不仅仅是扩容机器这么简单，建立和使用合适的缓存机制才是根本。 最开始，我们的Web系统架构可能是这样的，每个环节，都可能只有1台机器。 我们从最根本的数据存储开始看哈。 一、 MySQL数据库内部缓存使用 MySQL的缓存机制，就从先从MySQL内部开始，下面的内容将以最常见的InnoDB存储引擎为主。 1. 建立恰当的索引 最简单的是建立索引，索引在表数据比较大的时候，起到快速检索数据的作用，但是成本也是有的。首先，占用了一定的磁盘空间，其中组合索引最突出，使用需要谨慎，它产生的索引甚至会比源数据更大。其次，建立索引之后的数据insert/update/delete等操作，因为需要更新原来的索引，耗时会增加。当然，实际上我们的系统从总体来说，是以select查询操作居多，因此，索引的使用仍然对系统性能有大幅提升的作用。 2. 数据库连接线程池缓存 如果，每一个数据库操作请求都需要创建和销毁连接的话，对数据库来说，无疑也是一种巨大的开销。为了减少这类型的开销，可以在MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候，再创建，空闲过多的时候，则销毁。 其实，还有更为激进一点的做法，使用pconnect（数据库长连接），线程一旦创建在很长时间内都保持着。但是，在访问量比较大，机器比较多的情况下，这种用法很可能会导致“数据库连接数耗尽”，因为建立连接并不回收，最终达到数据库的max_connections（最大连接数）。因此，长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务，控制CGI机器“盲目”创建连接数。 建立数据库连接池服务，有很多实现的方式，PHP的话，我推荐使用swoole（PHP的一个网络通讯拓展）来实现。 3. Innodb缓存设置（innodb_buffer_pool_size） innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区，如果机器是MySQL独占的机器，一般推荐为机器物理内存的80%。在取表数据的场景中，它可以减少磁盘IO。一般来说，这个值设置越大，cache命中率会越高。 4. 分库/分表/分区。 MySQL数据库表一般承受数据量在百万级别，再往上增长，各项性能将会出现大幅度下降，因此，当我们预见数据量会超过这个量级的时候，建议进行分库/分表/分区等操作。最好的做法，是服务在搭建之初就设计为分库分表的存储模式，从根本上杜绝中后期的风险。不过，会牺牲一些便利性，例如列表式的查询，同时，也增加了维护的复杂度。不过，到了数据量千万级别或者以上的时候，我们会发现，它们都是值得的。 二、 MySQL数据库多台服务搭建 1台MySQL机器，实际上是高风险的单点，因为如果它挂了，我们Web服务就不可用了。而且，随着Web系统访问量继续增加，终于有一天，我们发现1台MySQL服务器无法支撑下去，我们开始需要使用更多的MySQL机器。当引入多台MySQL机器的时候，很多新的问题又将产生。 1. 建立MySQL主从，从库作为备份 这种做法纯粹为了解决“单点故障”的问题，在主库出故障的时候，切换到从库。不过，这种做法实际上有点浪费资源，因为从库实际上被闲着了。 2. MySQL读写分离，主库写，从库读。 两台数据库做读写分离，主库负责写入类的操作，从库负责读的操作。并且，如果主库发生故障，仍然不影响读的操作，同时也可以将全部读写都临时切换到从库中（需要注意流量，可能会因为流量过大，把从库也拖垮）。 3. 主主互备。 两台MySQL之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了“单点故障”问题。任何一台故障，都还有另外一套可供使用的服务。 不过，这种方案，只能用在两台机器的场景。如果业务拓展还是很快的话，可以选择将业务分离，建立多个主主互备。 三、 MySQL数据库机器之间的数据同步 每当我们解决一个问题，新的问题必然诞生在旧的解决方案上。当我们有多台MySQL，在业务高峰期，很可能出现两个库之间的数据有延迟的场景。并且，网络和机器负载等，也会影响数据同步的延迟。我们曾经遇到过，在日访问量接近1亿的特殊场景下，出现，从库数据需要很多天才能同步追上主库的数据。这种场景下，从库基本失去效用了。 于是，解决同步问题，就是我们下一步需要关注的点。 1. MySQL自带多线程同步 MySQL5.6开始支持主库和从库数据同步，走多线程。但是，限制也是比较明显的，只能以库为单位。MySQL数据同步是通过binlog日志，主库写入到binlog日志的操作，是具有顺序的，尤其当SQL操作中含有对于表结构的修改等操作，对于后续的SQL语句操作是有影响的。因此，从库同步数据，必须走单进程。 2. 自己实现解析binlog，多线程写入。 以数据库的表为单位，解析binlog多张表同时做数据同步。这样做的话，的确能够加快数据同步的效率，但是，如果表和表之间存在结构关系或者数据依赖的话，则同样存在写入顺序的问题。这种方式，可用于一些比较稳定并且相对独立的数据表。 国内一线互联网公司，大部分都是通过这种方式，来加快数据同步效率。还有更为激进的做法，是直接解析binlog，忽略以表为单位，直接写入。但是这种做法，实现复杂，使用范围就更受到限制，只能用于一些场景特殊的数据库中（没有表结构变更，表和表之间没有数据依赖等特殊表）。 四、 在Web服务器和数据库之间建立缓存 实际上，解决大访问量的问题，不能仅仅着眼于数据库层面。根据“二八定律”，80%的请求只关注在20%的热点数据上。因此，我们应该建立Web服务器和数据库之间的缓存机制。这种机制，可以用磁盘作为缓存，也可以用内存缓存的方式。通过它们，将大部分的热点数据查询，阻挡在数据库之前。 1. 页面静态化 用户访问网站的某个页面，页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次，是通过动态CGI查询数据库获取之外，之后都直接将本地磁盘文件返回给用户。 在Web系统规模比较小的时候，这种做法看似完美。但是，一旦Web系统规模变大，例如当我有100台的Web服务器的时候。那样这些磁盘文件，将会有100份，这个是资源浪费，也不好维护。这个时候有人会想，可以集中一台服务器存起来，呵呵，不如看看下面一种缓存方式吧，它就是这样做的。 2. 单台内存缓存 通过页面静态化的例子中，我们可以知道将“缓存”搭建在Web机器本机是不好维护的，会带来更多问题（实际上，通过PHP的apc拓展，可通过Key/value操作Web服务器的本机内存）。因此，我们选择搭建的内存缓存服务，也必须是一个独立的服务。 内存缓存的选择，主要有redis/memcache。从性能上说，两者差别不大，从功能丰富程度上说，Redis更胜一筹。 3. 内存缓存集群 当我们搭建单台内存缓存完毕，我们又会面临单点故障的问题，因此，我们必须将它变成一个集群。简单的做法，是给他增加一个slave作为备份机器。但是，如果请求量真的很多，我们发现cache命中率不高，需要更多的机器内存呢？因此，我们更建议将它配置成一个集群。例如，类似redis cluster。 Redis cluster集群内的Redis互为多组主从，同时每个节点都可以接受请求，在拓展集群的时候比较方便。客户端可以向任意一个节点发送请求，如果是它的“负责”的内容，则直接返回内容。否则，查找实际负责Redis节点，然后将地址告知客户端，客户端重新请求。 对于使用缓存服务的客户端来说，这一切是透明的。 内存缓存服务在切换的时候，是有一定风险的。从A集群切换到B集群的过程中，必须保证B集群提前做好“预热”（B集群的内存中的热点数据，应该尽量与A集群相同，否则，切换的一瞬间大量请求内容，在B集群的内存缓存中查找不到，流量直接冲击后端的数据库服务，很可能导致数据库宕机）。 4. 减少数据库“写” 上面的机制，都实现减少数据库的“读”的操作，但是，写的操作也是一个大的压力。写的操作，虽然无法减少，但是可以通过合并请求，来起到减轻压力的效果。这个时候，我们就需要在内存缓存集群和数据库集群之间，建立一个修改同步机制。 先将修改请求生效在cache中，让外界查询显示正常，然后将这些sql修改放入到一个队列中存储起来，队列满或者每隔一段时间，合并为一个请求到数据库中更新数据库。 除了上述通过改变系统架构的方式提升写的性能外，MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许，从硬件层面解决问题，可以选择老一点的RAID（Redundant Arrays of independent Disks，磁盘列阵）或者比较新的SSD（Solid State Drives，固态硬盘）。 5. NoSQL存储 不管数据库的读还是写，当流量再进一步上涨，终会达到“人力有穷时”的场景。继续加机器的成本比较高，并且不一定可以真正解决问题的时候。这个时候，部分核心数据，就可以考虑使用NoSQL的数据库。NoSQL存储，大部分都是采用key-value的方式，这里比较推荐使用上面介绍过Redis，Redis本身是一个内存cache，同时也可以当做一个存储来使用，让它直接将数据落地到磁盘。 这样的话，我们就将数据库中某些被频繁读写的数据，分离出来，放在我们新搭建的Redis存储集群中，又进一步减轻原来MySQL数据库的压力，同时因为Redis本身是个内存级别的Cache，读写的性能都会大幅度提升。 国内一线互联网公司，架构上采用的解决方案很多是类似于上述方案，不过，使用的cache服务却不一定是Redis，他们会有更丰富的其他选择，甚至根据自身业务特点开发出自己的NoSQL服务。 6. 空节点查询问题 当我们搭建完前面所说的全部服务，认为Web系统已经很强的时候。我们还是那句话，新的问题还是会来的。空节点查询，是指那些数据库中根本不存在的数据请求。例如，我请求查询一个不存在人员信息，系统会从各级缓存逐级查找，最后查到到数据库本身，然后才得出查找不到的结论，返回给前端。因为各级cache对它无效，这个请求是非常消耗系统资源的，而如果大量的空节点查询，是可以冲击到系统服务的。 在我曾经的工作经历中，曾深受其害。因此，为了维护Web系统的稳定性，设计适当的空节点过滤机制，非常有必要。 我们当时采用的方式，就是设计一张简单的记录映射表。将存在的记录存储起来，放入到一台内存cache中，这样的话，如果还有空节点查询，则在缓存这一层就被阻挡了。   异地部署（地理分布式） 完成了上述架构建设之后，我们的系统是否就已经足够强大了呢？答案当然是否定的哈，优化是无极限的。Web系统虽然表面上看，似乎比较强大了，但是给予用户的体验却不一定是最好的。因为东北的同学，访问深圳的一个网站服务，他还是会感到一些网络距离上的慢。这个时候，我们就需要做异地部署，让Web系统离用户更近。 一、 核心集中与节点分散 有玩过大型网游的同学都会知道，网游是有很多个区的，一般都是按照地域来分，例如广东专区，北京专区。如果一个在广东的玩家，去北京专区玩，那么他会感觉明显比在广东专区卡。实际上，这些大区的名称就已经说明了，它的服务器所在地，所以，广东的玩家去连接地处北京的服务器，网络当然会比较慢。 当一个系统和服务足够大的时候，就必须开始考虑异地部署的问题了。让你的服务，尽可能离用户更近。我们前面已经提到了Web的静态资源，可以存放在CDN上，然后通过DNS/GSLB的方式，让静态资源的分散“全国各地”。但是，CDN只解决的静态资源的问题，没有解决后端庞大的系统服务还只集中在某个固定城市的问题。 这个时候，异地部署就开始了。异地部署一般遵循：核心集中，节点分散。 核心集中：实际部署过程中，总有一部分的数据和服务存在不可部署多套，或者部署多套成本巨大。而对于这些服务和数据，就仍然维持一套，而部署地点选择一个地域比较中心的地方，通过网络内部专线来和各个节点通讯。 节点分散：将一些服务部署为多套，分布在各个城市节点，让用户请求尽可能选择近的节点访问服务。 例如，我们选择在上海部署为核心节点，北京，深圳，武汉，上海为分散节点（上海自己本身也是一个分散节点）。我们的服务架构如图： 需要补充一下的是，上图中上海节点和核心节点是同处于一个机房的，其他分散节点各自独立机房。 国内有很多大型网游，都是大致遵循上述架构。它们会把数据量不大的用户核心账号等放在核心节点，而大部分的网游数据，例如装备、任务等数据和服务放在地区节点里。当然，核心节点和地域节点之间，也有缓存机制。 二、 节点容灾和过载保护 节点容灾是指，某个节点如果发生故障时，我们需要建立一个机制去保证服务仍然可用。毫无疑问，这里比较常见的容灾方式，是切换到附近城市节点。假如系统的天津节点发生故障，那么我们就将网络流量切换到附近的北京节点上。考虑到负载均衡，可能需要同时将流量切换到附近的几个地域节点。另一方面，核心节点自身也是需要自己做好容灾和备份的，核心节点一旦故障，就会影响全国服务。 过载保护，指的是一个节点已经达到最大容量，无法继续接接受更多请求了，系统必须有一个保护的机制。一个服务已经满负载，还继续接受新的请求，结果很可能就是宕机，影响整个节点的服务，为了至少保障大部分用户的正常使用，过载保护是必要的。 解决过载保护，一般2个方向： 拒绝服务，检测到满负载之后，就不再接受新的连接请求。例如网游登入中的排队。 分流到其他节点。这种的话，系统实现更为复杂，又涉及到负载均衡的问题。 小结 Web系统会随着访问规模的增长，渐渐地从1台服务器可以满足需求，一直成长为“庞然大物”的大集群。而这个Web系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。 系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。