数据库隔离

      虚拟机部署数据库（我认为在自己练习环境可以，正式环境还是算了）。数据库作为系统的核心，资源一定要独享。甲骨文说如果Oracle安装在虚拟机上，都不提供支持。如果一个物理机上运行一个database比如（MySQL这里的X PostgreSQL这里的X）

，

这样的其实有点浪费，那么可能应该有多个。可能会有说现在微服务应该把数据库分开。其实我想说微服务和数据库是不是分开没有关系。一个实例下不同database也能去做。

     不过我更加说句心里话，真心话。那就是不用微服务更好，说这话可能招来一片嘘声。但是就我帮别人公司处理的经验来说，不用微服务的稳定多了。我问对方负责人，你这个不用微服务架构简单还稳定为什么要用？负责人说，不搞这些都招不到人。别人一听你没有用新技术，不来了。这就是当今现实，别管好用不好用，新的就追逐。

    这个还能达成共识，下面的就比较难了。放在一起一个database里面的SQL写的不好，会影响这个实例上所有的database。的确是这样的。不过一般来说管理上应该管好，大厂给出的经验就是上线前审核。不过国内大部分公司根本不重视这个，所以通常是以拆数据库的方式维持着烂SQL冲击数据库。所以时至今日，我只要看到一个人简历上写着擅长分库分表，而且不是一线大厂，就从心里不喜欢。中小公司的业务还要分库分表说明，这写的也太差了。以前有人问，我A数据库和B数据库可以合并吗？我问，您能遵守开发规范吗？对方想了想说，那还是分开吧。言下之意是，我不能遵守。

    现实就是这样残酷怎么办？前几天在技术群内看到有人提出要做多租户，多租户也要面对这个问题。一个租户（database）无节操的使用资源，其他租户（database）怎么办？而这种又是非正规开发或者就是不能服从管理的人员或者团队（SQL写的差其实真的是管理问题还不是技术问题）。那就只有一个办法了，资源隔离。

      资源隔离有两个方面：

1、 限制最大的，确保资源使用不会超限。比如虚拟机设置，包括我们数据库Oracle的SGA_MAX_SIZE，MySQL的innodb_buffer_pool_size等参数，这种都是让这种资源不得超过设定的阈值。

2、 保证最小的，确保资源至少供给。比如很多参数的默认值，其实都是保证最小不能低于这个。要求在使用资源的时候隔离出一个最小资源，有点像最低工资，要保证这个数据库在大环境不好的情况下，也要活下去。不能因为整体资源紧张，就放弃了它。

    就我实际经验而言，内存是最好限制的。IO是最难限制的，这里到不是说他的取值多难，而是他会连带把CPU也拖进来。我经历过一个案例是，意外的并发对一个表全表查询，每次将近300万次的IO物理读，这样大量的并发访问某些个别资源，产生大量I/O等待，造成系统CPU的异常升高，从用户态转移到内核态，从而影响了全部。当时缺乏对CPU的限制。不过我觉得那个IO限制也使得我们有机会去重启单个PDB，而不用整个CDB重启。

     估计很多厂商都在考虑这个课题，不好做。相对好做的还是，请遵守数据库的开发规范。这个非常容易，禁止的不要做；不能避免的看看是设计错了，还是需求错了。

（编辑：泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!