项目实例:全部商品页要求多种排序，并且作为2C端需要性能要求

需求如下:

针对全部在售的商品，能够根据当前商品的

1*上下架时间--需要能够切换顺序倒序列 

2*价格(对应角色不同价格不同) ------需要能够切换顺序倒序列 

3*当前商品角色的是否可见性(不可见则剔除当前排序中)

4*是否售罄(售罄沉底)

 

原计划是把所有的数据全部获取到，然后根据要求进行排序，将当前排序下的所有数据定时存储在redis中,再根据前端的参数从redis中获取分页数据。

缺点:

1.取到的数据量过大，每次都是整个数据库的全表查询，对性能要求高。

2.取到的数据进行sort排序，计算量过大，对性能要求高。

3.缓存数据量过大，针对角色*4，针对上架时间*2,针对价格*2,需要准备全部商品页的redis为16份。

4.缓存更新的数据量过大。

5.会出现商品的错漏少情况。

6.对应的售罄状态来自于库存模块实时查询要求太高。

 

描述一下6的问题

如果是使用分页操作提供给前端的话，会出现较多的问题，因为后台的排序是实时的，分页获取到的实时对应排序是有误的。

(售罄和价格的变动会实时影响商品的位置,假设原先未售罄商品A(排序为1)转为售罄商品A(末置位)的时候在多次获取排序的过程中变为售罄，导致部分商品排序上移动而**消失不见**，在全部商品页的最底下再次出现已经显示的商品A(末置位))

假设一共20个商品.

总排序如下

ABCDEFGHIJKLMNOPQRST

假设获取第一页获取前10个商品，1-10商品。     ABCDEFGHIJ

第二页获取后10个商品，11-20的商品。              KLMNOPQRST

这是正常显示。

但是实际会发生的情况如下:

 ABCDEFGHIJ,KLMNOPQRST

 AEFGHIJKLM,NOPQRSTBCD

但是会出现的问题是  第一次刷新的时候  ABCDEFGHIJ  中   BCD售罄，后端再次排序

假设获取第一页获取前10个商品，1-10     ABCDEFGHIJ

第二页获取后10个商品，11-20。              NOPQRSTB(售罄)C(售罄)D(售罄)

导致BCD重复出现。IJK则无法显示。

 

 

目前想法如下:

想法如下:使用redis或者某技术方案进行实时排序存储。

一次性返回前端所有的商品的spuCode(做好排序逻辑),

(条件触发原则如下)当下次切换角色，切换上下架时间排序，切换价格排序，才再次提供对应排序的所有spuCode。

app端使用提供的spuCode的list自行来查询，并且提供一个对应接口

根据传入的spuCode，按照spuCode传入的顺序提供spu的list详细数据的接口(对应的每个spu数据是存储在redis中)。

 

Redis  具体逻辑如下:

使用Redis 有序集合(sorted set)

 

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

 

假设价格逻辑优先于角色,

key=当前商城的角色_价格排序逻辑_上架时间逻辑(是否售罄的逻辑放在分数里Score中,因为会频繁变动)   作为集合的名称

设置某个spuCode或者是skuCode 对应的score是: 

首逻辑(是否售罄，1和0表示)+次逻辑（考虑到商城最多为百万，预留一定的位数）+二级逻辑(对应的上架时间戳)