前言

去年写了一篇文章介绍客户标签系统的设计，限于文章篇幅，只能粗略的介绍个大概。今天补个小节，关于标签ID的一个小设计。

回顾

回顾一下去年的基本假设：有1000万的用户，运营团队定义了100个标签，虽然不是每个用户都会有100个标签，但按最大的假设计算，系统需要保存10亿的标签。这是一个非常庞大的数据量。要应用标签，就会涉及大量的规则运算，那如何才能在规则运算的过程中有更好的性能表现呢？

一个小技巧是在标签的ID上做些设计。每个标签由标签键(tag key)+标签值(tag value)组成，每个标签ID统一为32位。

标签ID的设计.png

表示Tag Key 的16位可以使用数据库自增ID，或者类似的自增方式，保障标签的唯一表示。
将这几种标签的数据类型（Boolean, varchar, 整数区间，浮点数区间，日期时间区间，规则类）纳入到标签ID的表达里，是为了提升计算机程序的处理性能，更方便的查缓存、分配内存。
标签值（tag value），需要确保在key内是唯一。在不同的tag key，tag value的12位数可以有重复。
对于boolean类型的标签，例如各种黑白名单，tag value（12bits部分）固定用了0与1分别表示false 与 true。
所有标签ID（tag key ID + tag value data type + tag value ID）都使用以上ID生成器生成。
一般公司的有效标签key在1000个以内，这一般与公司运营团队的人数相关。一个人能大概知道其表示的意义并利用的标签数量是有限的。标签体系定义的标签个数太多是不会有运营的意义的，没有运营人员能记住数千个标签的定义并应用于运营工作。
如果某个标签可枚举的值超过4K个，则要重新思考对这个标签的定义，它不应该是一个标签。
这样设计的标签ID，可支持65536个标签，而每一个标签最多可枚举4K个值。即使考虑到公司有多个运营团队，标签的删除或失效，65536个标签的数量也足以满足多数公司的需要。
标签比指标更有深度、更凝练，是定性不定量的。

虽然给1000万个用户打标签，可能会有10亿个标签。但运营团队只定义了100个标签，标签的定义表只是一个很小的表，可以在应用服务器完全缓存起来。10亿个标签只是Customer ID与 Tag ID的简单的关联，可以有很多种分库分表的方式处理。

一般在用户访问进来时，是确定的1位用户，找到这个用户下的标签也就数十个。直接解析数十个Tag ID，就可以直接关联到缓存中的Tag对象，不需要在数据库中join操作，也不需要再访问Tag表。
可以在配置营销规则时，将Tag ID直接写到规则的表达式里，成为表达式变量的数字化表达。这样在规则运算时，根本不需要解析Tag ID，直接逻辑运算。