自己做电商也有3年多了，是不是可以写写电商基本的购物车实现呢。目前我们使用购物车的存储方式主要有：Session方式，Cookie方式，数据库存储，我们来一一分析优缺点。
1.Session（Memcached）方式
优点：购物车信息保存在服务端，可以保存1M 信息。
缺点：对于大型网站会占有过多的服务器内存资源，造成服务器压力过大。Session保存的信息会在用户退出登录后丢失。用户下次登录，购物车中商品信息丢失，用户只能从新选择。
2.Cookie方式
优点：购物车信息存储在客户端，不占用服务器资源，基本可以到达持久化存储。
缺点：Cookie有大小的限制，不能超过4K，而且不够安全。如果是个人PC机，Cookie能很好的保存购物车信息，但如果是公共办公环境，Cookie保存的信息基本就失效了(会被其他人购物车信息覆盖)。对一个大型的电子商务网站，我们需要对用户的购买行为进行分析，需要对用户推荐用户感兴趣的商品，如果把购物车信息保存在Cookie中，则不能对用户购买行为分析统计。
3.数据库存储
优点：持久化存储，可以分析用户购买行为。
缺点: 网站速度变慢，成本和维护增加。
对于一个大型的电子商务网站，我们需要知道用户对什么样的商品感兴趣，需要给用户推荐相似度商品。那么就有必要分析用户的购买行为。在这里只详细讲述下使用数据库存储方式的演变。开始我们是使用Cookie存储购物车的信息，但使用一段时间后发现有很多客户投诉，购物车中常常会多了很多商品，而且并不是客户选择的商品。数据挖掘部门也抱怨不能分析购物车的信息。。。。我们决定改变购物车的存储方式。开始我们设计的表是这样的：
对于登录用户，我们根据UserId查询购物车信息。对于非登录用户，则根据浏览器选择查询方式，如果是火狐浏览器，我们根据SessionId查询，如果是IE或360浏览器，我们根据IP查询。在一天订单量只有几万单的时候，系统运行的很稳定。但发现一天订单量超过10万单的时候，特别是高峰期，购物车数据库写压力特别大。查询也时常超时。我们不得不清理存储时间超过10天的数据。我们新建一个Job每天夜里执行删除超过10天的数据。但随着订单量的增加。数据库写压力依然很大。这时候我们考虑分库来解决数据库的写压力。我们根据登录用户和匿名用户来拆库。
对于登录用户我们根据UserId拆成2个库，一个是奇数库，一个是偶数库。对于匿名用户我们根据浏览器拆分，火狐浏览器（SessionId查询）一个库，IE或360浏览器（根据IP查询）一个库。
对于表结构，我们也做了调整。使用UserId和CreatedDateTicks时间撮做联合主键，
登录用户购物车表结构：
匿名用户（火狐浏览器）存储表结构：
IE或360浏览器存储表结构：
数据存储方面我们也做了调整。删掉了大量的数据库更新操作，因为大量的更新操作会造成锁表。购物车信息发生变化时，Content保存用户购物车信息的XML。现在只需做插入操作了。查询数据时，返回最后一条数据即可。采用分库后减轻了单台数据库写数据的压力，Content保存购物车信息的XML避免大量的更新操作。现在系统可以平稳的运行了！【相关教程推荐】
2. php从入门到精通
3. bootstrap教程
