关于配额管理数据库的一种构想

目前项目中遇到一个需求，需要私有云在单独机房下的实例数量。需求本身很简单，最简单的做法就是给每个机房添加一个单独的字段表示最大配额。但是在和团队一起碰撞下，一致认为这个需求的背后可能会有无数个奇葩的需求。想象一下，今天想要限制机房下的实例数量，明天想要限制某种实例的数量，后天又想限制某个机房某个环境的实例数量……这一个需求能够衍生出无数的类似的需求，所以我们决定做一个相对通用的方案。经过两天的思维碰撞，我把这个想法总结了一下。

其实可以把这个配额管理的场景在抽象一下，主要的难点就是需要在有多个不同限制条件(不同的字段)的情况下，随机组合条件进行搜索。想了那么久，现在记录下来的时候，却突然感觉那么简单了。基本的数据结构如下:

target_id: 目标主体的id
target_type: 目标主体的类型
pattern: 多个条件的组合
pattern_type: 被限制目标的属性的类型
privority: 优先级
min: 最小值
max: 最大值
remain: 剩余值

这里的target_type是指我们要限制的目标的类型，而pattern_type是指我们要限制目标的属性的类型。比如我要限制总共有几个机房，那么target_type就是指机房ROOM，而pattern_type就是指数量MOUNT，再比如要限制机房的实例的数量，那么target_type就是指机房ROOM，而pattern_type就是指实例INSTANCE。

最大值最小值剩余值都不用解释。如果业务简单，最大最小值可以仅仅用一个limit字段来表示，remain也可以直接在需要的时候直接查询数据库count一下。

最重要的是pattern字段，我最先的设想是每个限制条件都被表示为数据库的一个字段，如果没有该值则为空，查询的时候直接用SQL的OR来进行筛选。但是我同事有更好的想法。仅仅用一个字段来表示条件，多个不同的条件用分隔符分开。pattern_type为实例的时候，条件可能为磁盘类型、系统类型和环境类型，那么这三个条件组成一个序列:disk:system:env，如果仅仅限制disk那么可以存储成disk:ALL:ALL，这里用ALL代表该条件不对该条件进行限制；如果限制disk和env，那么可以存储成disk:ALL:env。最后在实际搜索时使用正则匹配一下即可。这种实现方式相当于用target_type和pattern_type来唯一确定pattern的样式，这样不同type的条件可以放在一个字段中，也就规避了不同配额类型限制条件不同造成的增加表或者增加表字段的局面。

这只是目前的一个初步构想与实践，满足我们当前的需求当然是绰绰有余了，不过是否能入我们预期的那样满足今后的一些变态需求，就要看时间的考验了。