作者介绍

@知乎:邹志全

专注营销系统提效,

自动化营销精细运营的长期实践者,

做有效编码,

“数据人创作者联盟”成员。

接上篇文章:我认知中的营销活动及其系统(一)

01

营销系统设计的问题域

01

需求特点

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


02

技术特点

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


03

安全&风险

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


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

02

我认为营销系统的样子

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


01

方案选择

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


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



02

营销系统架构

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



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



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

03

常用组件

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


01

唯一单号服务

这个组件非常非常重要,所以会说的相对仔细。在繁多的业务场景下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同样需要进行划分命名空间。


02

规则引擎

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

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


03

价值交换组件

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

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

点赞(322) 打赏

Comment list 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部