隐隐觉得自己在提升。哈哈！！

    

    刚开始什么业务都放在数据库的Proc里面，写得多了，改的多了，想的多了，发现很难复用，不能集中维护，业务的东西，还是应该更多的放在代码里面处理，这样提高复用，利与维护，而且后期还可以做中间件，开放接口，甚至开放平台。

    放在代码里面的粒度也是个需要纠结的地方，需要仔细考量。

    拿电子商务来说吧，购物车和收藏夹中的商品需要显示最新的价格，而不是添加时候的价格，而且用户的一些信息会决定这个价格。这个问题有很多做法。刚开始我是在获取购物车的Proc中一并join所有表，加上sum，mix等等聚合函数，然后查询出所有结果。这就需要在购物车和收藏夹中都存在这样的代码，根据商品ID和用户ID，查询最新价格。

    后来多了之后，发现不止这两个地方存在，很多地方都有这个需求。拆分吧，必须要独立出来了，而且不要放在proc里面了，也不是说不能放在里面，写一个公共的proc，其他proc调用这个公共的proc，就可以了。但是总觉得不是很好，维护还是不方便，而且版本管理也不方便，这些属于业务的东西，还是用代码来管理比较好。

    好吧，写个函数。写函数也经历了两个阶段，

    第一个阶段，每个产品ID和用户ID的组合写一个方法，在方法里面调用数据库proc，返回该产品、该用户的购买价格。在获取购物车之后，循环购物车元素，然后调用这个方法。这个貌似可以了，购物车东西少还行，或者说用户少也还可以，而且粒度很小，到处可以用，不管什么地方，只要是需要产品最新价格的地方都可以使用。可是由于需要放在循环里面访问，每次访问都会链接数据库，查询，返回。循环比较大的话，很浪费资源。就有了第二阶段。

    第二个阶段，产品ID用逗号链接起来，一次性传入proc，在proc解析，然后一次性查询几个产品的价格，一次性返回结果集合。这样就打打减少了数据库连接的次数，性能得到了提升。在大规模之后还是很明显的。

    有没有第三阶段呢？

    在知道了缓存，甚至是分布式缓存之后，而且知道了存储容量的规划是很有必要的，无论是持久化的容量规划，还是内存的容量规划，都需要进行量化的设计。现在的内存还是很便宜的，将大量数据缓存起来，可以减少很多的数据库连接，减少很多的IO，可以极大的提升系统性能。

    商品的价格信息随时都会使用，而且单个商品的这类信息按照100K来算（100K还是可以放很多东西的，1K=1024B，一个字符1B，一个汉字2B），10个商品=1MB，10000个商品=1GB，现在的服务器，哪个没有32GB的内存呢？是不是，何况是集群呢？

    大概的思路是这样的：

    这类信息其实可以大量的缓存，在后台更新产品的同时，更新对应的缓存。前台访问的时候，先从缓存里面获取，如果没有再从物理存储中读取。

    使用分布式缓存，集中管理缓存的存取，使得前台的集群都可以访问缓存，提高缓存的命中率。

    还需要较好的处理缓存的失效，还需要注意缓存的大面积失效导致的大量访问直接请求物理存储，导致IO出现瓶颈。

    还会需要一个缓存监测系统，随时监测缓存的运行情况。

    好吧，先说到这里，欢迎大家拍砖！！

    感谢你非常有耐心的看完本文！