核心模块开发思路

(Updated: )
工作

智能码

分配

  1. 从缓存/db中获取渠道码信息，判断是按时段还åå是按ip分配还是随机分配

按IP

wlid:user:xid 存放 externalUserRelatedId
2. 先判断当前用户的xid是否已经绑定某客户，若客户已添加过员工，则返回该员工的二维码。
3. 若是已流失的企业客户
channel:wlid:code:xid 存放RedisLiveCode
4. 看是否分配过，如果渠道码信息一致则直接返回，
不一致，如果分配过且二维码使用员工匹配，
5. 若员工不匹配，
** livecode: codeChannelId** 存放RedisLiveCode队列
若缓存中可以取到，返回，没有取到则从数据库中拿到码的列表放入缓存中并取得码返回
6. 若员工匹配
** livecode: codeChannelId:userId**
若缓存中可以取到码，将该码存入** channel:wlid:code:xid，并返回
若没有取到，则将渠道中的码全部取出更新缓存 livecode: codeChannelId:userId** 并取得码再存入** channel:wlid:code:xid后返回
7. 若没有分配过，上锁
** lock:code:select:xid RLock锁
再获取一遍channel:wlid:code:xid
若取到则和上面步骤一致，看渠道和员工一不一致并获取返回
8. 若未取到，先获取** special:code:channel:ip:codeChannelId，若未取到则从数据库中读取并存入缓存
** special:code:channel:ip:codeChannelId 存放 Map<IpRegionCodeList, componentRuleId> map
** ip:region:ipAddress** 存放IpAddressDto
** channel:user:pool: componentRuleId** 存放员工id
special:channel:codeId:codeId 存放region
9. 遍历获取到的map，IpRegionCodeList中存在当前ip，则根据componentRuleId从** channel:user:pool: componentRuleId中取出对应员工，若没有缓存，则从数据库中查出后放入缓存
10. 根据获取到的员工从 livecode: codeChannelId:userId** 取码，取出后同步放入channel:wlid:code:xid 和 special:channel:codeId:codeId中并返回
11. 若map中不存在当前ip，则返回默认员工的码

###随机分配

生成码时打乱队列即可

###按时段

定时任务按时段切换智能码对应员工

归因

用户行为监测

track

  1. 前端请求track
  2. 用户浏览时拦截器种下cookie
  3. 监控用户浏览信息 每5s一次 持续5分钟

区分用户的行为类型： 打开 or 停留

open track

  1. 根据 {xid} 和 {ui} 查找缓存

  2. 若不存在缓存，查找该cookie是否存在历史事件，若999历史事件绑定了客户，则清除该客户画像的缓存（产生了新画像事件）

  3. 根据当前用户访问信息构造根事件和子事件并生成缓存

    ** 缓存及存放内容**
    key — value
    website:track:xid — rootEvent的开始结束信息 当前子事件
    website:track:ui — rootEvent的开始结束信息 当前子事件
    track:stay:website — 键值对 xid-当前时间 ui-当前时间

  4. 返回生成子事件的ID

stay track

  1. 根据xid/ui获取website:track缓存
  2. 获取不到则return，如果有责更新时间缓存数据

** 缓存及存放内容**
website:track:xid/ui rootEvent结束时间
track:stay:website — 键值对 xid-当前时间 ui-当前时间

find Expire（定时轮询）

  1. 获取track:stay:website map
  2. 遍历map
    1. 读取value，当前时间-事件发生时间，超过10s没有更新时间，则认为事件过期，进行事件过期处理，否则跳过继续进行监控
      1. 根据key中的xid/ui寻找website:track:xid/ui 获取事件的详细信息
        1. 若详细信息为空，则清除缓存
        2. 若不为空则根据缓存中信息更新数据库中事件的持续时长
      2. 如果当前xid没有分配过活码，清除缓存
      3. 判断事件是否活归因到活码加人，如果是，更新事件的用户信息，清除用户画像缓存
      4. 如果没有归因到活码加人，但识别到关联的历史客户，同样更新本次访问产生的所有事件的信息
      5. 判断是否有track:stay:doubleexpire:eventID事件过期缓存
        1. 没有就设置（只有xid/ui中的一个过期），有的话（两个都过期）则发送浏览通知

微信分享行为

merge

人找事件

  1. 加好友回调时，发送到TOPIC, “ATT.USERTOEVENT.SH2”
    HistoryAttributiveDTO：存放state等加好友回调信息
  2. 优先判断codeid+unionid的微信环境的归因，再判断是否能只根据codeid来进行归因

    ** 缓存及存放内容**
    ** attributive:history:unionid:state**
    ** attributive:history:state**
    存放内容为HistoryRedisDTO：存放码分配时的情况
    如果在缓存中找不到，因为history产生会早于加人事件，则判断这人不用归因

  3. 根据获取到的码当时的分配情况，将客户id写入分配记录，并删除上面state的缓存
  4. 根据分配时的target归因到具体场景，寻找当时的事件。
  5. 若为资料库场景，根据资料id和unionid找到事件。

    ** 缓存及存放内容**
    ** attributive:event:materialid:unionid** 存放eventLogId

    1. 将客户绑定到所有关联事件
    2. 若事件发生比加好友时间早，则将好友关系绑定到该事件，否则return
    3. 若为web场景，根据xid/ui查找
      ** 缓存及存放内容**
      ** attributive:event:xid** 存放eventLogId
      ** attributive:event:ui**
      若找不到，可能是没有cookie，使用ua过期了的，判断是否能从relation中获得事件，如果从relation获取到了事件，将客户绑定到所有关联事件
      并判断是否需要将好友关系归因到事件，如果归因成果的话删除上面缓存
    4. 如果还没找到，则将followUser归因后的信息放入redis中，有xid和ui两种key，并将HistoryRedisDTO设置为需要等待合并
      ** 缓存及存放内容**
      ** attributive:user:xid ** 存放HistoryMergeDTO
      ** attributive:event:ui**
  6. 如果不需要等待事件找到人，直接更改用户状态

事件找人

  1. 产生web访问时、资料浏览时，创建eventLog，并发送到TOPIC “ATT.EVENTTOUSER.SH2” eventLogId
  2. 根据eventLog中的xid 获取缓存

    ** 缓存及存放内容**
    ** attributive:user:xid **
    ** attributive:event:ui**
    找到缓存后将相关事件绑定到人，并删除上面缓存
    没找到的话则将事件放入缓存等待加人后合并
    ** 缓存及存放内容**
    ** attributive:event:xid** 存放eventLogId
    ** attributive:event:ui**

#资料库

auth