我认知中的营销活动及其系统（二）

接上篇文章：我认知中的营销活动及其系统（一）

营销系统设计的问题域

上面着重说了常见的营销活动类型，粗略介绍了面向的场景。如果大家经常使用一个产品或者关注一个产品，就会发现各类营销活动层出不穷，每个细节都是营销的样子，几乎每天看都会有新的不同。这种直观感受侧面反映出营销活动相关需求的特点：1、需求量无比巨大，且多变 2、时间紧急，倒排需求通常占80%以上 面对这样的情况，增加人力&临时借调，是一种解决方案，但也只能算是下策，不可能为营销投入50%以上的人力（但是我感觉pdd可能是50%以上，也可能是营销系统已经非常成熟），临时借调研发效率、质量等都有不小的风险。作为一个技术人员，我们要做的就是“以技术手段解决工程效率问题”，这就要求我们能需要做一种功能丰富且更加灵活易用营销系统，来达到小需求简单配置可上线，大活动释放降低80%以上的人力成本的目的。

性能要求较高（成败往往就在峰值） 营销活动的访问量通常较大，而且峰值突出。拿春晚活动、娱乐节目来说，通常是伴随口播等引导动作带领用户参与的，80%的用户都会集中在那一分钟左右涌入，而只是依赖于加机器是不现实的，降级限流等只会白白浪费流量并且造成负面营销，营销大促场景下，我们需要的就是抗。

上面频频提到了薅羊毛，这其实就是营销系统面临的非常重要的一个问题：资损 资损的来源通常有活动设计、代码实现、羊毛党的大量存在等多方面的原因，尤其是在这样的需求特点及大环境因素下，营销系统是一个极易发生资损的点。

下面就来看一下是如何用技术的手段解决上述问题，及其中核心系统&组件的实现原理。

我认为营销系统的样子

先看一下上面提到的两个概念或者说实体：营销：营销学关于企业如何发现、创造和交付价值以满足一定目标市场的需求,同时获取利润的学科。活动：在时间、场景、成本限制下，对不同用户根据不同规则进行权益投放，以达到获客、经营、品牌传播等目的最终构成交易的行为。然后结合业务领域，根据营销场景下的问题域（现在&将来），通过技术手段解决效率&质量问题，以此最终确定系统的职责、定位及内部架构。这一板块的内容十分庞大。

对于方案的选择通常有这么几个标准：人力成本、研发质量成本、研发效率成本、机器成本 一个系统方案的实现，最优的是人力、机器投入较少的情况下，能够确保质量的最快支持需求。对于营销类系统来说就是：建设非常通用且高性能的基础设施组件，实现相对通用的系统支持常规迭代，紧急且重大的需求依赖基础设施进行特化实现。像支付域、广告域的这些系统，面对的需求虽然也不少但是主要逻辑是确定的，一般都是对链路、功能进行丰富和优化。而营销场景下的需求讲真的，千奇百怪，除了上述所说的一些固定类型的活动形式及基础的活动单元，很多时候伴随运营的临时且全新的想法，我们需要面临决策，全新临时方案 or 通用解决方案的抉择。 

通用的系统这个大家都能接受，但对于当前所要实现的逻辑显然不能复用的情况，我的建议是采用全新的临时方案仅依赖基础组件，新的数据存储、新的server，一切只为解决当前临时需求。因为就风险和成本来说，实现一个临时方案相对于改一个相对复杂的系统要简单的多，并且风险完全收敛，我们也能集中精力解决当前问题，而不是竭尽所能把系统建设的啥都可配制化，看似系统牛逼，但为了暂时的需求，投入产出比太低。营销场景下永远都有临时且重大的需求，我们要做的是成本投入较小的情况下快速迭代。

系统功能：1、对业务系统或直接对用户提供营销能力输出 2、向业务方提供营销业务的配置化能力 3、提供效果洞察、成本、资损监控能力。

理想目标：常规活动配置化可上线，大型活动节省80%以上成本。活动效果可洞察，资损&故障易发现 系统架构：

活动流程层主要为构建实现营销活动流程实现能力的标准化输出，以活动单元能力或活动组件基础能力为原子单位，进行活动流程编排。活动单元层：提供常用营销活动的能力（比如抽奖、秒杀、邀请），每个单元面向一类营销形式，对外暴露标准接口。内部依赖于活动组件。活动组件：提供标准的单一的营销功能（签到、分享）或业务能力（价值交换、标签输出）或系统能力（调度组件、权益高效发放）等。权益系统：主要包含业务场景下内部权益、现金权益、外部权益，提供权益的实际发放、核销能力。数据处理：主要针对数据库（mysql、redis）、日志数据等数据进行标准化处理，为监控、数据一致性提供数据源 监控方面：对业务方提供可视化、标准化的效果展示，及资损监控&系统监控等能力。对账补单：提供数据一致性的最后一层保障。

常用组件

要开始深入技术细节啦，这块内容背后的知识体系基本就是我这1年8个月的基础技术能力的成长了，选几个具有代表性的组件来说。

这个组件非常非常重要，所以会说的相对仔细。在繁多的业务场景下n多系统的交互场景下，我们通常需要一个唯一id来作幂等处理，同时海量的数据（DB、log等）我们也需要一个唯一单号作为线索完成高效的数据分析工作，所以说每个请求、每个环节我们都是需要唯一id的。看到上述背景，不难想到唯一单号服务所面临的核心问题 功能性要求 1、唯一性保障 2、业务相关性且安全 系统要求 3、高性能 4、高可用 这四点即是难点，也是唯一单号的特征。唯一单号服务的实现方案有很多种，最常见的有自增键、UUID、雪花算法、Leaf-segment三种方案。 自增键 利用自增键是最容易想到的一种方式，实现方式通常有mysql主键自增、redis incr。但这两种方式很显然都会存在单点的问题，而且自增主键性能受限、redis 易发生数据丢失（性能只是相对mysql更好），但实现大学作业的时候还是可以用的，真实生产环境是肯定不会选用的。uuid UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx的36个字符,具体标准可见：http://www.ietf.org/rfc/rfc4122.txt（墙），目前业界有5种常用的生成uuid的方式。这种方式优点是性能高，纯本地生成，无网络IO发生。 

缺点也很突出：存储方面：1、不易存储（实在太长了） 2、这类id由于通常要落库并挂索引，对于mysql来讲，UUID的无序性会使数据位置频繁变动，严重影响性能，尤其是作为主键的情况下（主键越短越好） 业务相关&安全性：1、最常用的基于mac地址生成的方式会暴露mac。2、无任何业务标示，排查问题和统计时十分不便。 雪花算法 雪花算法最初是推特用于标记消息的，跟uuid结构类似，通过划分命名空间实现，基于时间戳+机器码+业务标示实现，这种方式极易横向扩展，由于是本地生成，且每台机器码值都不同，可用性和性能都得到了保证。并且灵活的结构添加业务标示也变的轻松了许多。

实现方式与uuid相似，虽然相对提及会小一些，存储方面的问题稍微得到缓解。但是有一个很严重的风险点，一旦发生时钟回拨，那就很惨了 mongoDB使用的就是这样方式。Leaf-segment 这种方式是我除雪花算法外最看好的实现方式 依赖于mysql存储保证数据不丢，并且利用行锁保证单调递增，一张表维护多个活动的id，通过异步化的方式批量批发单号对外提供服务保证性能，多个单号批发商对外提供服务并容忍单号浪费以此保证可用性。这段话可能说不明白直接看代码和图：

mysql可以只用一个，通常来说内存中大量的号段足以支撑mysql恢复，如果想用多个mysql同样需要进行划分命名空间。

在任何配置化的场景下规则引擎都是核心的存在，通常来说表达式在可视化的配置化后台，结合配置模版+配置元数据编译成“规则”，规则在执行时被翻译成表达式或者执行从而达到业务逻辑可编排，决策逻辑可配制的作用。

规则引擎一抓一大把，大家自行百度即可。基础的规则引擎中表达式的生成与解释也是营销场景非常常用的，比如波兰表达式等，涉及标签的地方就大概率涉及波兰表达式。

这里的价值交换组件指的是营销场景下，营销活动系统中各种“积分”、“代币”、“机会”等价值载体的交换体系，不同的活动单元中所使用的价值载体是不同的，要串联几个组件完成整个“大活动”的正常运作，出上层的规则引擎外，更重要的就是不同价值载体之间的转换，比如说“抽奖机会”<——>"任务积分"<——>"权益"。价值交换组件的场景更像是一种存在汇率的转账系统（但是相对转账来说，要简单的多，通常是单向并不可退的，仅仅作为系统逻辑转换的内部存在）. 可以简单看一下价值交换组件的内部实现：

cache、异步记账等存粹为了性能,其中最核心的点就是数据一致性问题，这个点会在后面单独介绍。