美文网首页技术架构
购物车实现之Cookie、Session、数据库优缺点分析

购物车实现之Cookie、Session、数据库优缺点分析

作者: 转身一世琉璃白_4a57 | 来源:发表于2018-09-03 15:05 被阅读0次

    目前我们使用购物车的存储方式主要有:Session方式,Cookie方式,数据库存储,我们来一一分析优缺点。
    1.Session(Memcached)方式

    优点:购物车信息保存在服务端,可以保存1M 信息。
    缺点:对于大型网站会占有过多的服务器内存资源,造成服务器压力过大。Session保存的信息会在用户退出登录后丢失。用户下次登录,购物车中商品信息丢失,用户只能从新选择。

    2.Cookie方式

    优点:购物车信息存储在客户端,不占用服务器资源,基本可以到达持久化存储。
    缺点:Cookie有大小的限制,不能超过4K,而且不够安全。如果是个人PC机,Cookie能很好的保存购物车信息,但如果是公共办公环境,Cookie保存的信息基本就失效了(会被其他人购物车信息覆盖)。对一个大型的电子商务网站,我们需要对用户的购买行为进行分析,需要对用户推荐用户感兴趣的商品,如果把购物车信息保存在Cookie中,则不能对用户购买行为分析统计。

    3.数据库存储

    优点:持久化存储,可以分析用户购买行为。
    缺点: 网站速度变慢,成本和维护增加。

    对于一个大型的电子商务网站,我们需要知道用户对什么样的商品感兴趣,需要给用户推荐相似度商品。那么就有必要分析用户的购买行为。在这里只详细讲述下使用数据库存储方式的演变。开始我们是使用Cookie存储购物车的信息,但使用一段时间后发现有很多客户投诉,购物车中常常会多了很多商品,而且并不是客户选择的商品。数据挖掘部门也抱怨不能分析购物车的信息。。。。我们决定改变购物车的存储方式。开始我们设计的表是这样的:

    图片1.jpg

    对于登录用户,我们根据UserId查询购物车信息。对于非登录用户,则根据浏览器选择查询方式,如果是火狐浏览器,我们根据SessionId查询,如果是IE或360浏览器,我们根据IP查询。在一天订单量只有几万单的时候,系统运行的很稳定。但发现一天订单量超过10万单的时候,特别是高峰期,购物车数据库写压力特别大。查询也时常超时。我们不得不清理存储时间超过10天的数据。我们新建一个Job每天夜里执行删除超过10天的数据。但随着订单量的增加。数据库写压力依然很大。这时候我们考虑分库来解决数据库的写压力。我们根据登录用户和匿名用户来拆库。采用如图方式

    图片2.jpg

    对于登录用户我们根据UserId拆成2个库,一个是奇数库,一个是偶数库。对于匿名用户我们根据浏览器拆分,火狐浏览器(SessionId查询)一个库,IE或360浏览器(根据IP查询)一个库。
    对于表结构,我们也做了调整。使用UserId和CreatedDateTicks时间撮做联合主键,登录用户购物车表结构:

    图片3.jpg

    匿名用户(火狐浏览器)存储表结构:

    图片4.jpg

    IE或360浏览器存储表结构:

    图片5.jpg

    数据存储方面我们也做了调整。删掉了大量的数据库更新操作,因为大量的更新操作会造成锁表。购物车信息发生变化时,Content保存用户购物车信息的XML。现在只需做插入操作了。查询数据时,返回最后一条数据即可。采用分库后减轻了单台数据库写数据的压力,Content保存购物车信息的XML避免大量的更新操作。现在系统可以平稳的运行了!

    一般来说,可以使用session,cookie和数据库来记录购物车数据
    1,不过不提倡使用session,这货占用服务器资源,还有过期时间,客户关掉浏览器时session即消失,下次再上来,又得重新选产品。
    2,cookie这东西不错,放在客户端的,给个一年的过期时间,只要客户不清掉,每次来都能记得上次的购物车信息。大家可以看看京东,
    在购物车cookie中存了不少东西,有产品编码和购买的数量等信息,如京东:yCartOrderLogic={&TheSkus&:[{&Id&:437741$&Num&:2}]},
    原来凡客的cookie中也以JSON的形式存了很多信息。
    所以,我以学习的心态,将产品编码,价格,名称,类型和数量等购物信息做成一个对象,然后对象序列化成JSON,存在客户端的COOKIE中,
    在读取cookie时,在刚开始的时候很好用,反序列化cookie值成购物车条目对象就可以了,但是当产品类型多起来之后,而且有套装那种多件产品时,
    甚至产品不是来自同一个数据表时,比如普通首饰和钻石,表的结构都不一样了,还得到不同的表格中去取,当然首先你得判断产品类型
    这时候一个购物条目对象已经有多条子对象,往往一个查询中嵌套着两重以上的循环加上多个switch case,当购物车中有十个复杂的条目时,读取速度
    将超过十秒,不管怎么优化,速度就摆在那里,不快不慢。。。而且你不能保证客户不下100个或更多的复杂购物车记录,最重要的是cookie是有
    存储大小限制的,这种做法有产品很复杂时是不利的,果断放弃!
    3,数据库这东西好啊,不会像cookie那种容易丢失,也没有客户端的限制,你想怎么存,存多少都行。

    购物车数据存数据库好处有很多,可以分析购买行为,可以为客户保存购买信息(不会因为浏览器关闭而丢失)等。
    还需要考虑的一个问题是用户是否登录,淘宝使用的就是cookie记录,你可以试试,未登录时可以加20个商品,登录后可以加50个,这就是因为
    cookie客户端的限制。
    我这里因为产品线的复杂性,所有购物车条目都保存在数据库中。

    购物车数据库设计成两个关联表
    1,Basket,购物车主表
    基本字段有:BasketId,AddTime,UserId,AddressId,Payment,Status等,不解释了,看英文意思就行
    2,BasketDetail,购物车条目表
    基本字段有:BasketDetailId,BasketId,Type,Code,Qty,ParentId等,ParentId用作子行标识,其它不解释
    两个表之间使用BasketId做为关联
    当用户登录状态时,添加产品到购物时,查看Basket中是否有Status为True的购物车,没有则添加一条新的Basket记录,并将产品信息相关数据添加至BasketDetail表中
    当用户未登录时,使用cookie记录一个BasketId值,不往Basket表中插入数据,只往BasketDetail插入数据,其中的BasketId值使用cookie中的BasketId值,当用户登录
    后,查看Basket中是否有Status为True的购物车记录,有则合并(更新cookie和BasketDetail中的BasketId为查询出来的Basket表中的BasketId值),无则添加一条新的
    Basket记录,并将BasketId值置为Cookie中记录的basketid值。
    (转载CSDN随风飘扬中博主的博文)

    相关文章

      网友评论

        本文标题:购物车实现之Cookie、Session、数据库优缺点分析

        本文链接:https://www.haomeiwen.com/subject/ydabwftx.html