持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第7天，点击查看活动详情
一、前言
商城是近期的一个项目，由于之前的经验匮乏，只能寻求网络上的解决方案，也就是因为这一举动，深深陷入的技术陷阱。 网络上的项目部分是demo项目，也就是没有经过实际生产测试过的，实现方式往往很暴力，有时并不适合业务环境。
二、什么是浏览历史
当我们打开掘金、知乎等知识内容APP时，在个人页面总会有一个浏览历史的功能，里面总会记得最近的一些阅读痕迹。在电商中也不例外，在自己的浏览记录里很方便得去寻找相应的商品。 那这个浏览历史主要是提供一个记录，能够很快的找到曾经的记录，这也就是说若干月前的记录是没有记录的必要的，因为人本身都不会记得，它具有时效性，但需要记录足够快，浏览后立即查询便能够查到。了解了相应的场景就可以进行设计实现方式了。
三、浏览历史实现
不具有时效性
在淘宝中只会记录近几月的浏览记录，在知乎中记录近3000篇文章，也就是说一半没人去翻阅五六个月前的浏览，几千篇文章。
检索
最直观影响效率的就是检索速度了 方案一：使用数据库表，当用户点击浏览离开始记录到数据库表，然后落库操作。 方案二：使用缓存，把浏览记录放在缓存中。
这两个方案的区别在于，缓存可以很好的支持速度要求，但是不满足于数据安全，一旦断电等问题，没有落库会导致数据丢失。
浏览记录也不能一味地存储，一般只存储近两个月的数据，或者数据量达到几百之后，再之前的数据就没必要去记录。
隐藏需求
在浏览历史中，还有一个要求，如果点击某个记录后，他的位置会发生变化，例如点击一星期前的记录再次查询时，他的位置变成刚刚阅读，这样快速定位且改变排序顺序。
说到这里渐渐落库的方案开始出现劣势，因为是浏览历史，对于数据的要求性没有订单那样要求严格，所以这边建议使用缓存的方式实现，而且可以使用Map的方式，快速定位。
四、数据一致问题
既然我们引入了缓存，当检索的时候，总会遇到数据不一致的问题，例如浏览时商品名称为A，之后的时间里修改成了B，那我们有没有必要把数据的信息进行同步呢？
我的理解是不需要，当时查看的内容和记录不相同的话会有歧义。
五、实现方式
我们可以使用MQ的方式，异步去存储，监测页面关闭时发送消息，以异步的方式处理以免影响正常的请求导致系统效率降低。
