什么都不谈之一，从业务角度看分布式，架构，开发，管理

前言

鄙人在进入IT行业没有被淘汰的一点就是业务能力有点强，虽然技术不咋地。大部分业务都能实现。虽然没有轻视过业务。可是心底仍是以为技术是很是重要。比业务重要。越到后来，发现不是这样的。 完成一个产品那么技术与业务二者都不可欠缺。没有什么熟轻熟重。技术是为了更好的服务业务，没有业务，产品没法更加健壮。业务想要更好的体验感等须要技术实现。因此二者是相辅相成。 有时须要技术作得更多，可能提升运营的工做效率，提升合做愉快。 有时须要业务退让下，技术可能很好的实现，技术风险与成本可能下降不少。

合做，不是要求。合理的退让，多作点就好

优惠券案例

优惠券是一种很是有效的推销，营销方式。是运营，商业推进消费的一种重要手段。技术若是实现很差，他们会跟你拼命。

公司用户群体越大，活动查看，优惠券领用的并发越高。

优惠券的使用不能影响下单，支付，退款的响应时间

优惠券查看功能

缓存，缓存所有缓存。缓存实际上是一个很麻烦的东西。能不用就不用。

缓存的几个性能指标

1. 容量，容量越大维护越复杂，硬件成本越高。有效缓存数据是重点
2. 缓存命中率

在用户角度来讲，能看到的业务也就只有优惠券活动，与优惠券。

一个优惠券活动规则： 　　　　不限定数量。能够有N个领用者，每一个领用能够领用N张 领用者*每人领用张数＝总数 　　　　活动限定数量。

一个活动对应 限定数量或者领用者*每人领用张数 的优惠券。

活动出现的场景

1. 活动介绍页面
2. 领用页面
3. 提醒点（下订单的时候，会提醒用户，购买的商品有优惠券可使用）

分析获得

1. 活动宣传页面，会被大量用户点击 活动数据是热点数据
2. 每领一张优惠券，那么必须关联一个或者多个活动才能领取。能领取的活动是大热点数据
3. 活动过时一个星期以内，用户点击率不到1%，一个星期以后点击率几乎为零， 失去热点。冷却了。从缓冲中删除
4. 活动数据量远远小于优惠券数据量
5. 用户冷不丁的查看过去活动。如何处理。这个几率很低，仍是会出现。

热点数据必须缓存

冷了的数据若是处理

1. 冷了数据从缓存中删除。保证内存中数据的有效性，与高度的命中
2. 若是用户冷不丁的查看过去活动。没有命中缓存，能够查库。id查询很快的。

优惠券出现场景

1. 优惠券查询页面
2. 下订单时，提醒优惠券可使用
3. 某个活动页面进入须要识别用户是否拥有优惠券，依据不一样优惠券显示不一样的视图效果

优惠券的数量极其庞大

1. 做为用户，领取了。至于能不能用到，会不会去用，比不了，先领了在说的想法。领取的数量会十分庞大。。淘宝，天猫，京东，双11活动。几乎重要的店铺都会有多种优惠券。大概估值：一个店铺发放总数为一百万张，平均领取五十万，重要店铺两万。双十一当天与前几天的优惠价领取量可能达到百亿（感受低估了）。
2. 优惠券基本类型有 未使用，已使用，已过时。（重点）

通过分析点

1. 下订单时，提醒优惠券可使用 场景

能使用的类型只有 未使用的优惠价

2. 优惠券查询页面

常常网购的你，在下面图片中三个状态优惠券你点击最多的，不会点击的是？

这三类操做中，用户对未使用点击率是99%，已使用的为0.99%，已过时的为0.01%。

3. 三个状态优惠券的特性分析

已使用与已过时的优惠券是有大量陈旧数据。已使用的优惠券的特性。导致这张优惠券永远保存。有些平台会清除过于陈旧的已过时的优惠券。有些平台会把于陈旧的已使用的优惠价也清除。

从分析的点得出一下结果

未使用的优惠券是超级热点数据，其余类型优惠券基本没有人查看。因此未使用与未生效的数据是放到内存中，提升响应速度，内存命中率基本达到99%。内存容量减小，数据有效性为99% 其余类型的优惠券能够从缓存中删除，须要时从数据库中查。这种很大程度上节约了内存服务器资源，减小了架构复杂度与成本。优惠券模块的分布式更加简单了。节约了运营成本，运维成本。开发更加简单。 天生为数据库资源隔离最好了准备

产品退一步，技术更好的实现。

不要到处跟淘宝，天猫比。他们每个细节都大量的用户考验。每一个考验后面有无数优秀的程序员和产品经理日以继夜分析，实现，完善。

多学习下淘宝，天猫，京东的设计，他们每个细节都大量的用户考验。把适合本身的拉过来用。