【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
前言
鄙人在进入IT行业没有被淘汰的一点就是业务能力有点强，虽然技术不咋地。大部分业务都能实现。虽然没有轻视过业务。但是心底还是觉得技术是非常重要。比业务重要。越到后来，发现不是这样的。 完成一个产品那么技术与业务两者都不可欠缺。没有什么熟轻熟重。技术是为了更好的服务业务，没有业务，产品无法更加健壮。业务想要更好的体验感等需要技术实现。所以两者是相辅相成。 有时需要技术做得更多，可能提高运营的工作效率，提高合作愉快。 有时需要业务退让下，技术可能很好的实现，技术风险与成本可能降低很多。
合作，不是要求。合理的退让，多做点就好
优惠券案例
优惠券是一种非常有效的推销，营销方式。是运营，商业推动消费的一种重要手段。技术如果实现不好，他们会跟你拼命。
公司用户群体越大，活动查看，优惠券领用的并发越高。
优惠券的使用不能影响下单，支付，退款的响应时间
优惠券查看功能
缓存，缓存全部缓存。缓存其实是一个很麻烦的东西。能不用就不用。
缓存的几个性能指标
- 容量，容量越大维护越复杂，硬件成本越高。有效缓存数据是重点
- 缓存命中率
在用户角度来说，能看到的业务也就只有优惠券活动，与优惠券。
一个优惠券活动规则： 不限定数量。可以有N个领用者，每个领用可以领用N张 领用者*每人领用张数＝总数 活动限定数量。
一个活动对应 限定数量或者领用者*每人领用张数 的优惠券。
活动出现的场景
- 活动介绍页面
- 领用页面
- 提醒点（下订单的时候，会提醒用户，购买的商品有优惠券可以使用）
分析得到
- 活动宣传页面，会被大量用户点击 活动数据是热点数据
- 每领一张优惠券，那么必须关联一个或者多个活动才能领取。能领取的活动是大热点数据
- 活动过期一个星期之内，用户点击率不到1%，一个星期之后点击率几乎为零， 失去热点。冷却了。从缓冲中删除
- 活动数据量远远小于优惠券数据量
- 用户冷不丁的查看过去活动。如何处理。这个概率很低，还是会出现。
热点数据必须缓存
冷了的数据如果处理
- 冷了数据从缓存中删除。保证内存中数据的有效性，与高度的命中
- 如果用户冷不丁的查看过去活动。没有命中缓存，可以查库。id查询很快的。
优惠券出现场景
- 优惠券查询页面
- 下订单时，提醒优惠券可以使用
- 某个活动页面进入需要识别用户是否拥有优惠券，依据不同优惠券显示不同的视图效果
优惠券的数量极其庞大
- 作为用户，领取了。至于能不能用到，会不会去用，比不了，先领了在说的想法。领取的数量会十分庞大。。淘宝，天猫，京东，双11活动。几乎重要的店铺都会有多种优惠券。大概估值：一个店铺发放总数为一百万张，平均领取五十万，重要店铺两万。双十一当天与前几天的优惠价领取量可能达到百亿（感觉低估了）。
- 优惠券基本类型有 未使用，已使用，已过期。（重点）
经过分析点
- 下订单时，提醒优惠券可以使用 场景
能使用的类型只有 未使用的优惠价
- 优惠券查询页面
经常网购的你，在下面图片中三个状态优惠券你点击最多的，不会点击的是？
这三类操作中，用户对未使用点击率是99%，已使用的为0.99%，已过期的为0.01%。
- 三个状态优惠券的特性分析
已使用与已过期的优惠券是有大量陈旧数据。已使用的优惠券的特性。致使这张优惠券永远保存。有些平台会清除过于陈旧的已过期的优惠券。有些平台会把于陈旧的已使用的优惠价也清除。
从分析的点得出一下结果
未使用的优惠券是超级热点数据，其他类型优惠券基本没有人查看。所以未使用与未生效的数据是放到内存中，提高响应速度，内存命中率基本达到99%。内存容量减少，数据有效性为99% 其他类型的优惠券可以从缓存中删除，需要时从数据库中查。这种很大程度上节约了内存服务器资源，减少了架构复杂度与成本。优惠券模块的分布式更加简单了。节约了运营成本，运维成本。开发更加简单。 天生为数据库资源隔离最好了准备
产品退一步，技术更好的实现。
不要处处跟淘宝，天猫比。他们每一个细节都大量的用户考验。每个考验后面有无数优秀的程序员和产品经理日以继夜分析，实现，完善。
多学习下淘宝，天猫，京东的设计，他们每一个细节都大量的用户考验。把适合自己的拉过来用。
来源：oschina
链接：https://my.oschina.net/u/1261452/blog/3033533