# 故事
梅雨季，闷热的夜，令人窒息，窗外一道道闪电划破漆黑的夜幕，小猫塞着耳机听着恐怖小说，辗转反侧，终于睡意来了，然而挨千刀的手机早不振晚不振，偏偏这个时候振动了一下，一个激灵，没有按捺住对内容的好奇，点开了短信，卧槽？告警信息，原来是负责的服务出现慢查询了。小猫想起来，今天在下班之前上线了一个版本，由于新增了一个业务字段，所以小猫写了相关的刷数据的接口，在下班之前调用开始刷历史数据。
考虑到表的数据量比较大，一次性把数据全部读取出来然后在内存里面去刷新数据肯定是不现实的，所以小猫采用了分页查询的方式依次根据条件查询出结果，然后进行表数据的重置。没想到的是，数据量太大，分页的深度越来越深，渐渐地，慢查询也就暴露出来了。
# 故事
“不能在写if else来拓展当前系统了，现在已经有三个支付场景了......”工位上，小猫看着电脑，挠着头。
就在刚刚，小猫接到了一个新需求，需要和客户公司打通资产，形成资产联动。说白了就是需要定制化对接客户公司的支付资产体系。除了这次接到的之外。前面其实已经对接了三家了。由于每家对接规范都不一样，历史对接的时候为了尽快上线，都是直接搞个else的新路由分支，然后去实现支付，退款。
在小猫看来，就是在堆屎山。牵一发而动全身的感觉真的很不好。由于本次的需求留有的时间还是相当充裕的，所以小猫下定决心，打算利用这次的拓展，将原来不合理的地方用上设计模式将其重构掉。
深思熟虑很久，小猫下定决心打算用“策略模式”重构一番。
# 故事
这是一个真实事件，三年前老猫负责公司的支付资产业务。为了响应上级号召，加强国央企之间的合作，公司新谈了一个支付对接的渠道（当然这个支付渠道其实很冷门的，也是为了对接而对接，具体哪个渠道也不方便透露），由于原始支付系统的第三方支付可拓展性设计得还不错的，所以老猫对接的也是比较快的，熟悉对方的对接文档之后对着编码就好了，差不多花了三天的时间就完成联调了。一切看似很顺利地上线了。
时隔几天，收到了一个快递包裹，是一袋价值53块钱的“原皮腰果”，当时诧异，翻看了各大消费平台，都没有之前的下单记录，后来和媳妇确认了一下，她也没有下单。“难道是某个崇拜哥的小姑娘送的？不能吧”当时心里美滋滋地yy着。
不过之后的一个客诉问题，引起了老猫的重视，老猫排查下来发现一个很重大的问题，钱款的扣除和实际的订单状态对不上。说白了就是订单完结了，但是账户资产并没有完成扣除。我瞬间明白了之前那个“原皮腰果”是怎么回事儿了，当时在生产测试渠道的时候，在公司内部商城提交了订单，但是并没有付款，然而订单却成功了。
再三确认之后，确实存在这一问题。一瞬间整个人心态崩了，头皮发麻，口干舌燥，心脏“突突突”。怎么办？怎么办？生产还不知道涉及多少单子，没办法，兜不住了，先把这件事情往上抛吧（向上级领导汇报）。
具体原因是什么呢？我们来看一下对接第三方支付的大概时序流程。
# 故事
会议室里，小猫挠着头，心里暗暗叫苦着“哎，这代码都撸完了呀，改起来成本也太大了。”
原来就在刚才，组长找到了小猫，说代码review过程中发现有些数据表模型设计得不合理，要求小猫改掉。小猫大概是设计了一个配置表，为了省事儿，小猫直接把相关的配置设计成了text类型的存储形式。
关于这种业务场景下使用text文本类型存储，组长指出了以下缺点：
- 在内存中处理Text字段时，由于需要处理大量数据，可能会导致内存使用过度，影响数据库性能。
- Text字段无法创建索引，这会导致数据库在执行查询时无法利用索引来加速搜索。虽然可以通过全文索引来改善搜索性能，但是却会有诸多限制，例如只能用于InnoDB引擎，并且索引只能建立在不超过1000字节的前缀上。
- 目前刚设计的时候就用text类型，后期随着数据量的增长以及业务需求的变化，可能就意味着要将text类型继续扩大变成，LongText或MediumText类型，这样的转换既费时又可能需要额外的存储空间。
“组长说的也有道理，但是为什么现在才指出来，当时方案模型评审的时候咋提呢，哎，醉了醉了，现在业务逻辑都按照现有方案开发完了，才提出来.....”
“改？要重写逻辑，不改？万一今后真的出现上面组长说的这些问题，不得被喷死......”
彷徨过后，小猫终于下定了决心，改了吧，长痛不如短痛...反正如果不改的话，受罪的还是自己。于是加班是少不了了......
# 故事
地铁上，小帅双目空洞地望着窗外...绝望，发自内心地感到绝望...
距离失业已经过去两个月了，这是小帅接到的第四次面试邀请。“回去等通知吧...”,简简单单的六个字，把小帅的心再次打入了冰窖。
上次“【ThreadLocal问出花
“Java中的锁了解吧？介绍一下吧”，面试官不紧不慢地问到。