流控数据库

A. 阿里云 MSE 支持 Go 语言流量防护

随着 Go 语言和云原生技术的普及，Go 语言在微服务场景中的应用愈发广泛，对微服务治理和流量控制的需求也日益增长。在 Go 语言中，尽管社区提供了 go.uber.org/ratelimit 等限流库，但这些库存在局限性：仅支持 Go 语言，且功能上缺乏多语言兼容和动态配置，无法满足完善的限流降级需求。

阿里云微服务引擎（MSE）结合了业界先进的 Sentinel 技术，为 Go 语言和 Java 应用提供了全面的微服务治理能力。本文将详细讲解如何在 Go 语言微服务中利用 MSE 的限流降级功能。

限流降级在微服务中是通过三个步骤实现的：首先，设定目标接口（Target），如订单创建接口，限制其每秒请求量（Strategy）为1000次；当达到限流阈值后，返回异常（FallbackAction）以防止系统过载。

为了在 Go 语言应用中接入 MSE 的限流降级，首先在启动应用时，添加 MSE SDK 的初始化命令。在云原生部署中，推荐通过环境变量管理配置，以方便在不同环境间切换。MSE-Go-SDK 推荐使用特定的环境变量来连接 MSE。

接入后，可以在 MSE 控制台的“应用列表”页面查看已接入的应用。接下来，要定义资源（Target），MSE 支持使用 Sentinel 的资源定义，只需将业务逻辑包裹在 Sentinel 定义的代码块内。对于使用微服务框架如 Dubbo-go、Gin 或 gRPC 的开发者，可以利用相应的适配器自动注册资源到 MSE。

配置限流降级规则时，可以设置流控、隔离、熔断和热点规则。在应用详情页面，可以查看资源概览、代码中的资源注册以及规则设置的效果，如流量拒绝率、并发控制等。MSE 还在持续发展，计划支持 OpenSergo 标准，以实现不同语言微服务的统一治理，并探索流量治理、数据库治理等更多功能，为开发者提供全面的微服务治理解决方案。

如果您对 MSE 专业版或云原生网关感兴趣，可以享受折扣优惠。获取更多信息和下载链接，请参考相关链接。

B. 为什么要用 Tair 来服务低延时场景 - 从购物车升级说起

低延时服务是内存数据库Tair的核心能力，使其在高吞吐、大连接数、热点请求、异常流量、复杂计算逻辑、弹性伸缩等真实场景中保持稳定性能的关键。今年双十一期间，Tair作为购物车升级的核心产品，展示了大淘宝技术团队不断自我审视、追求更好的选择的精神。

体验提升通常意味着降低服务降级、提高数据实时性、减少调用链路的延迟。这需要从客户端到数据库组件的每一个环节提供最强的产品能力。在数据库层，挑战在于在访问量激增的同时，保持延时稳定和成本控制。Tair具备内存/SCM混合存储、水平扩展分区无锁和sql引擎等技术，这些技术在支撑双十一活动的过程中逐步完善，持续优化服务端性能。

存储引擎性能是低延时的基础，涉及并发、事务处理、快照等功能。Tair采用内存/SCM作为主要存储介质，提供单次访问延时在ns级别的性能。介质成本考量包括硬件选择和数据结构设计，如采用SCM降低存储成本，并通过透明压缩减少空间占用。索引方面，Tair使用多种数据结构如HashTable、SkipList、RBTree等，针对不同场景优化性能。

为应对高并发挑战，Tair采用RCU无锁引擎提升内存引擎性能，通过SQL场景下的多线程处理实现线性扩展，同时支持Serializable事务隔离，增强并发处理能力。在水平扩展方面，Tair支持数据分散到不同分区，提供稳定的低延迟服务。此外，针对连接数限制，Tair通过优化多线程IO能力、解耦IO线程和worker线程、实现轻量化连接等技术手段提高系统处理能力。

在异常场景处理方面，Tair通过热点策略、流控机制、执行流程优化等手段，确保系统在面对突发异常流量或特定请求时的稳定运行。热点处理采用智能路由和数据分散策略，减少单点压力。流控机制帮助系统识别并限制异常流量，保证正常服务不受影响。执行流程优化包括存储过程使用和Pipeline执行模型，减少解析和编译开销，提升执行效率。

随着Tair功能的扩展，从基础的KV存储到支持复杂数据结构和SQL查询，Tair已经成为提供低延时、高并发、数据安全的内存数据库解决方案。在购物车升级、销量统计、判店场景等双十一关键业务中，Tair展示了其强大的性能和灵活性。同时，Tair在技术创新和产品力上持续发展，包括发表顶会论文、独立产品上线、提供丰富数据处理能力等，为客户提供更广泛的价值。

综上所述，Tair通过核心的低延时服务，结合多维度的技术优化和场景适应能力，为双十一等关键业务场景提供了稳定、高效的数据处理支持，体现了其在低延时场景中的重要价值。

C. mysql中间件有哪些

mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡，读写分离，failover等，但其不支持大数据量的分库分表且性能较差。下面介绍几款能代替其的mysql开源中间件产品，Atlas，cobar，tddl，让我们看看它们各自有些什么优点和新特性吧。
Atlas
Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。
Altas架构：
Atlas是一个位于应用程序与MySQL之间，它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池。

以下是一个可以参考的整体架构，LVS前端做负载均衡，两个Altas做HA,防止单点故障。

Altas的一些新特性：
1.主库宕机不影响读
主库宕机，Atlas自动将宕机的主库摘除，写操作会失败，读操作不受影响。从库宕机，Atlas自动将宕机的从库摘除，对应用没有影响。在mysql官方的proxy中主库宕机，从库亦不可用。
2.通过管理接口，简化管理工作，DB的上下线对应用完全透明，同时可以手动上下线。

3.自己实现读写分离
（1）为了解决读写分离存在写完马上就想读而这时可能存在主从同步延迟的情况，Altas中可以在SQL语句前增加 /*master*/ 就可以将读请求强制发往主库。
主库可设置多项，用逗号分隔，从库可设置多项和权重，达到负载均衡。

4.自己实现分表
（1）需带有分表字段。
（2）支持SELECT、INSERT、UPDATE、DELETE、REPLACE语句。
（3）支持多个子表查询结果的合并和排序。

这里不得不吐槽Atlas的分表功能，不能实现分布式分表，所有的子表必须在同一台DB的同一个database里且所有的子表必须事先建好，Atlas没有自动建表的功能。
5.之前官方主要功能逻辑由使用lua脚本编写，效率低，Atlas用C改写，QPS提高，latency降低。
6.安全方面的提升
（1）通过配置文件中的pwds参数进行连接Atlas的用户的权限控制。
（2）通过client-ips参数对有权限连接Atlas的ip进行过滤。
（3）日志中记录所有通过Altas处理的SQL语句，包括客户端IP、实际执行该语句的DB、执行成功与否、执行所耗费的时间 ，如下面例子。
图4

7.平滑重启
通过配置文件中设置lvs-ips参数实现平滑重启功能，否则重启Altas的瞬间那些SQL请求都会失败。该参数前面挂接的lvs的物理网卡的ip，注意不是虚ip。平滑重启的条件是至少有两台配置相同的Atlas且挂在lvs之后。
source：https://github.com/Qihoo360/Atlas
alibaba.cobar
Cobar是阿里巴巴（B2B）部门开发的一种关系型数据的分布式处理系统，它可以在分布式的环境下看上去像传统数据库一样为您提供海量数据服务。那么具体说说我们为什么要用它，或说cobar--能干什么？以下是我们业务运行中会存在的一些问题：
1.随着业务的进行数据库的数据量和访问量的剧增，需要对数据进行水平拆分来降低单库的压力，而且需要高效且相对透明的来屏蔽掉水平拆分的细节。
2.为提高访问的可用性，数据源需要备份。
3.数据源可用性的检测和failover。
4.前台的高并发造成后台数据库连接数过多，降低了性能，怎么解决。
针对以上问题就有了cobar施展自己的空间了，cobar中间件以proxy的形式位于前台应用和实际数据库之间，对前台的开放的接口是mysql通信协议。将前台SQL语句变更并按照数据分布规则转发到合适的后台数据分库，再合并返回结果，模拟单库下的数据库行为。

Cobar应用举例
应用架构：

应用介绍：
1.通过Cobar提供一个名为test的数据库，其中包含t1,t2两张表。后台有3个MySQL实例(ip:port)为其提供服务，分别为：A,B,C。
2.期望t1表的数据放置在实例A中，t2表的数据水平拆成四份并在实例B和C中各自放两份。t2表的数据要具备HA功能，即B或者C实例其中一个出现故障，不影响使用且可提供完整的数据服务。
cabar优点总结：
1.数据和访问从集中式改变为分布：
（1）Cobar支持将一张表水平拆分成多份分别放入不同的库来实现表的水平拆分
（2）Cobar也支持将不同的表放入不同的库
（3） 多数情况下，用户会将以上两种方式混合使用
注意！：Cobar不支持将一张表，例如test表拆分成test_1,test_2, test_3.....放在同一个库中，必须将拆分后的表分别放入不同的库来实现分布式。
2.解决连接数过大的问题。
3.对业务代码侵入性少。
4.提供数据节点的failover,HA：
(1)Cobar的主备切换有两种触发方式，一种是用户手动触发，一种是Cobar的心跳语句检测到异常后自动触发。那么，当心跳检测到主机异常，切换到备机，如果主机恢复了，需要用户手动切回主机工作，Cobar不会在主机恢复时自动切换回主机，除非备机的心跳也返回异常。
(2)Cobar只检查MySQL主备异常，不关心主备之间的数据同步，因此用户需要在使用Cobar之前在MySQL主备上配置双向同步。
cobar缺点：
开源版本中数据库只支持mysql，并且不支持读写分离。
source：http://code.alibabatech.com/wiki/display/cobar/Home
TDDL
淘宝根据自己的业务特点开发了TDDL（Taobao Distributed Data Layer 外号:头都大了 ©_Ob）框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的 jdbc datasource实现，具有主备，读写分离，动态数据库配置等功能。
TDDL所处的位置（tddl通用数据访问层，部署在客户端的jar包，用于将用户的SQL路由到指定的数据库中）：

淘宝很早就对数据进行过分库的处理， 上层系统连接多个数据库，中间有一个叫做DBRoute的路由来对数据进行统一访问。DBRoute对数据进行多库的操作、数据的整合，让上层系统像操作一个数据库一样操作多个库。但是随着数据量的增长，对于库表的分法有了更高的要求，例如，你的商品数据到了百亿级别的时候，任何一个库都无法存放了，于是分成2个、4个、8个、16个、32个……直到1024个、2048个。好，分成这么多，数据能够存放了，那怎么查询它？这时候，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快（每条查询在几毫秒内完成），TDDL就承担了这样一个工作。在外面有些系统也用DAL（数据访问层） 这个概念来命名这个中间件。
下图展示了一个简单的分库分表数据查询策略：

主要优点：
1.数据库主备和动态切换
2.带权重的读写分离
3.单线程读重试
4.集中式数据源信息管理和动态变更
5.剥离的稳定jboss数据源
6.支持mysql和oracle数据库
7.基于jdbc规范，很容易扩展支持实现jdbc规范的数据源
8.无server,client-jar形式存在，应用直连数据库
9.读写次数,并发度流程控制，动态变更
10.可分析的日志打印,日志流控，动态变更