代理层(DAL)，最直观的需求是能做分库分表，能做读写分离，还可以做资源隔离、连接数隔离、连接的管理等，更重要的是还能对数据库进行相应的保护。

外卖业务大多数人都是在中午下单，所以 11 点左右是饿了么的业务高峰。

为了缓解数据库压力，我们会通过 DAL 层做削峰处理，当流量过大时我们会让用户消息做排队的处理，由此缓解对数据库的瞬间冲击。如果流量特别大的时候还可以做限流、熔断等处理。

还有黑白名单机制，大家了解数据库运维的话会知道，如果研发写的 SQL 有问题，放入到数据库里风险会比较高。

如果他现在发了一个删除表的 SQL 命令过来就有风险，我们的 DAL 就会把这类黑名单 SQL 给拒绝。

更高级一点的功能是多维分表以及全局表 Map Table 功能。有些配置表希望在所有机房都有，DAL 上就可以做 Global Table 的功能，可以保证在所有节点上都是同样的数据。

当然，DAL 做完这些功能后，对 SQL 也是有一些限制的。比方说事务，下单不能跨服务片去做事务。

很多传统的应用业务逻辑会把很多东西包在一个事务里完成，但互联网业务应该尽量减少这种应用，在底层分片后，业务事务并不能完全通过数据库里的事务来保障。

可能每个表分片维度不一样，会导致数据分布到不同的机器上，这样就需要跨服务器事务一致性的保障，所以业务就不能再依赖于数据库的事务，需要通过其他的机制来保证。

还有 Order by 、Group by 会受到限制，如果你查 Top10 的话，DAL 只会在一个分片上把 Top10 给到你，但并非是全局的。虽然有这些限制，但是与 DAL 带来的好处比是完全可以接受的。

SQL 治理

首先在 SQL 发布的时候，我们平台上的发布工具里面会内嵌需要遵循的标准，如果表建的时候不符合标准是没法生产提交的，这样就强制地把规则和标准变成硬性要求，SQL 还可以自动实现审核也节省了 DBA 很多时间。

另外，生产一旦出现变慢的 SQL 后，监控系统会马上把消息 Push 给研发，如果影响到生产运作的话会直接拒掉、查杀掉。

比方我们定义超过 30 秒的 SQL 是不允许线上产生的，这类 SQL 会被直接杀掉，这样可以大大减少生产的风险。