自如优品分销系统（lua+策略模式）

目录

一.业务背景：

二.技术实现

三.策略模式

四.问题答惑

---

一、业务背景：

2018 年，是自如充满机遇与挑战的一年，在年初成功获得了 40 亿 A 轮融资，自如客突破 200 万，管理资产直逼 200 万间。

快速扩张的同时，电商项目也随之发力。优品事业部周会是老板也会参加的例会，可谓内部的重点创业项目之一。

最近尝试一种新的分销模式，根据自如大体量的管家进行线下线上推广，通过活动的形式让用户领取优惠券，通过券促成单后管家可进行分佣。管家之间会在所属大区，所属小组分别进行排名，进行排名再奖励激发推广热情。想想还是蛮诱人的，毕竟赤果果的钱呀。

这个项目有几个明显需要重点关注的点

1. 涉及到钱的准确性：不发超不少发
2. 数据信息的及时性：分销金额与排名的实时查看
3. 动态性：管家因为调区调组带来的数据实时变动问题

快速迭代开发是php的优势呀，但是涉及到钱的问题，真的因该慎之又慎。最终选择了lua+redis的技术方案在服务端运行，保证活动的稳定性。

 

二.技术实现

1.为什么是lua?

Redis 从 2.6.0 版本起，,通过内置的 Lua 解释器,也已开始支持 Lua 脚本的执行。

我们可以更加得心应手地使用或扩展 Redis，特别是在高并发场景下 Lua 脚本提供了更高效、可靠的解决方案。

好处：

• 减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。
• 原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。
• 复用：客户端发送的脚本会永久存储在Redis中，意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。

 

2.设计方案：

分享推广环节不做过多叙述，重点分析一下订单相关流程，简化如图下所示，主要涉及三个部分。

 

因为我们使用的有赞云，做分销活动自然也绕不开订单的同步回传的问题，

当用户在有赞下单之后会以http的形式进行通知。接受时这里做了异步处理，把消息推入redis队列中等待处理，并返回成功结果给有赞。

同时再挂起进程对队列中的订单进行异步处理，通过Supervisor来监控进程的存活，发现订单任务堆积，可动态增加进程。

技术设计流程图如下，

 

                                                                        【用户下单】与【订单查分】处理示意图

 

拆分订单时，当发现是发货操作，通过基于elastic-job的分布式队列，写到作业当中。

把订单拆分逻辑与分佣计算异步解耦，只要成功扔到作业中即可，业务不必依赖于分佣逻辑的结果。

 

红色框中就是进行【分佣计算】的后续衔接部分，通过这个节点，分布式作业会对成功写入队列的任务进行执行，轮训执行与异常重试，当发现执行失败是会进行重试（10次）

通过redis+lua的形式保证数据一致性与原子性

通过redis-zset等结构保证排序查询性能问题

（注意：分佣逻辑做了幂等操作，防止补偿重试时发生超发现象）

3.lua+redis的使用

Redis 提供了 EVAL（直接执行脚本） 和 EVALSHA（执行 SHA1 值的脚本） 这两个命令，可以使用内置的 Lua 解析器执行 Lua 脚本。语法格式为：

EVAL script numkeys key [key …] arg [arg …]

EVALSHA sha1 numkeys key [key …] arg [arg …]

参数说明：

script / sha1：EVAL 命令的第一个参数为需要执行的 Lua 脚本字符，EVALSHA 命令的一个参数为 Lua 脚本的 SHA1 值

numkeys：表示 key 的个数

key [key …]：从第三个参数开始算起，表示在脚本中所用到的那些 Redis 键（key），这些键名参数可以在 Lua 中通过全局数组 KYES[i] 访问

arg [arg …]：附加参数，在 Lua 中通过全局数组 ARGV[i] 访问

lua+redis在php中的使用

$script = $this->luaScript();//以字符串的形式存储lua脚本

$data = array('key1','key2','value1');//在lua脚本中通过KEYS[1] KEYS[2], ARGV[1]的顺序获取

$keylen = 2;//表示$data中前两个值是key，表示key的个数

$res = static::$redis->eval($script ,$data,$keylen);

 

三.策略模式

　　在软件开发中也常常遇到类似的情况，实现某一个功能有多个途径，此时可以使用一种设计模式来使得系统可以灵活地选择解决途径，也能够方便地增加新的解决途径。

策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

而我们这个分销计算场景中，有初始化create场景，有累加incr场景，有delete场景，甚至还有动态调配所有值的场景，并且使整个体系核销能对的上。那么策略模式就很适合了。

redis;

}

$this->strategyName = $this->file_pre.ucwords(strtolower($strategyName)).'Logic';

}



public function deal()

{

  try{

    $namespace = '\\' . __NAMESPACE__ . '\\';

    $class_name = $namespace.$this->strategyName;

    $exists = class_exists($class_name);

        if (!$exists) {
            return $this->fail_return('非法访问,该策略不存在'); 
        }

        $strategyReflection = new \ReflectionClass($class_name);

        $strategy = $strategyReflection->newInstance();

        return $strategy->run();

    }catch(\ReflectionException $e){

        return $e->getMessage();

    }

  }

}



Interface ProfitStrategyLogic

{

/**

* 任务执行

* @return mixed

*/

public function run();



/**

* 存储lua运行脚本

* @return mixed

*/

public function +luaScript();



/**

* 处理拼接lua所需key值与value值

* $param $data

* @return mixed

*/

public function dealData();

}



class ProfitLuaAddLogic extends ProfitDataLogic implements ProfitStrategyLogic

{

public function run()

{

$deal = $this->dealData();

static::$redis->eval($this->luaScript(),$deal['data'],$deal['key_length']);

}



    public function luaScript()

    {    
    $luaScript = <<dealData();

static::$redis->eval($this->luaScript(),$deal['data'],$deal['key_length']);

}



public function luaScript()

{

$luaScript = <<deal();

策略模式提供了可以替换继承关系的办法,继承可以处理多种算法或行为

优点：

1.规范性可标准拓展：策略模式提供了可以替换继承关系的办法,继承可以处理多种算法或行为。

2.策略模式提供了可以替换继承关系的办法,继承可以处理多种算法或行为。

3.使用策略模式可以避免使用多重条件转移语句。

缺点：

1.客户端必须知道所有的策略类，并自行决定使用哪一个策略类。

2.策略模式造成很多的策略类，每个具体策略类都会产生一个新类。

四.问题答惑

1、php中如何调试lua脚本

在php中执行的lua脚本其实是通过redis的eval函数嵌入原子执行的，单纯的打印或者写日志的方法都是行不通的，所以说调试起来还比较麻烦。好在php的redis扩展中也加了异常捕获，可以通过：

var_export(static::$redis->getLastError());

来返回脚本中发生的错误。

 

2.为什么不使用redis事务

redis中的事务并不像mysql中那么完美，只是简单的保证了原子性。

事务的实现原理是把事务中的命令先放入队列中，当client提交了exec命令后，redis会把队列中的每一条命令按序执行一遍。如果在执行exec之前事务中断了或未提交，则统一不执行。

而redis确保正一条script脚本执行期间，其它任何脚本或者命令都无法执行。正是由于这种原子性，script才可以替代MULTI/EXEC作为事务使用。

官网文档上有这样一段话：

A Redis script is transactional by definition, so everything you can do with a Redis transaction, you can also do with a script, and usually the script will be both simpler and faster.

 

3.如何保证原子性

因为Redis是单线程。Redis本身提供的所有API都是原子操作，所以Redis中的事务其实是要保证批量操作的原子性

举个例子，卖商品

$goods_num = $redis->get('goods_num');

if($goods_num<1){

return false;

}else{

//todo sale logic

$goods_num = $redis->set('goods_num',0);

}

当高并发时，有可能就会出现redis还没有set成功0，新的访问又进来了，结果执行了两次售卖逻辑，但脚本中的get set是原子性操作时则不会发生这样的问题的。

 

4.如何保证数据一致性

为了达到数据最终一致性，我们引入了基于elastic-job的分布式作业有失败重试机制，生成一个全局唯一的外部订单号，当某分佣发放失败，就会放回任务队列，使得有机会进行发放重试，当然这一切都需要 API 做幂等处理。这样就保证了不超发也不会少发。

public function luaScript()

{

$luaScript = <<0 --如果已经做过处理，返回true表示执行成功过

then

return true

end



local guanjia_hash = redis.call('hget', KEYS[1],'name')

if not guanjia_hash

then

--初始化hash

redis.call('HMSET', KEYS[1], KEYS[9], ARGV[9],KEYS[10], ARGV[1],KEYS[16], ARGV[2],KEYS[17], ARGV[3])

else

--管家调区刷新信息

redis.call('HMSET', KEYS[1] , KEYS[10], ARGV[1],KEYS[16], ARGV[2],KEYS[17], ARGV[3])

--金额累加

redis.call('HINCRBY', KEYS[1],KEYS[9],ARGV[9])

end



--幂等

redis.call('SADD', KEYS[13],ARGV[10])

--初始化管家小组排名

redis.call('ZINCRBY',KEYS[2],ARGV[9],ARGV[1])

--初始化管家大区排名

redis.call('ZINCRBY',KEYS[3],ARGV[9],ARGV[1])

--更新小组总排名

LUA;

return $luaScript;

}

需要注意 Lua 脚本执行过程并不是事务的，脚本中的操作命令在执行时是有先后顺序的，当某个操作执行失败时不会回滚已经执行成功的操作，它的原子性是通过单线程模型实现。

 

客单价 = 总金额/购买商品数量 

动销率=有销量的商品/在线销售的商品 

成单率=订单数量 / 累计进店客户

短信召回率：发券召回人数

 

参考文章：

https://redis.io/commands/eval

https://blog.csdn.net/fangjian1204/article/details/50585080

https://www.cnblogs.com/yanghuahui/p/3697996.html

https://blog.csdn.net/zjf280441589/article/details/52716720

Redis 的操作为什么是的原子性的详解：https://blog.csdn.net/qq646040754/article/details/81066805