缓存优化v2.docx

缓存优化1 现状目前 已有 cache：blackListDB = redisfactory.getDB(1)user_cache = redisfactory.getDB(2)result_cache = redisfactory.getDB(3)COUNTER_CACHE = redisfactory.getDB(4)PRELOAD_DEVS = redisfactory.getDB(5)REGEXCONFIG = redisfactory.getDB(8)firstlayer_cache = redisfactory.getDB(11)device_cache = redisfactory.getDB(12)channels_cache = redisfactory.getDB(13)REWRITE_CACHE = redisfactory.getDB(15)1=post BlackList , preload_cache2=user_cache3=search result_cache4=splitter COUNTER_CACHE8=RegexConfig_cache10 = device_BU11=firstlayer_cache12=device_cache13=channels_cache15=REWRITE_CACHE5=PRELOAD_DEVS对应rcms 所有 cache：firstlayer_cache = redisfactory.getDB(11)device_cache = redisfactory.getDB(12)channels_cache = redisfactory.getDB(13)对应rcmp 的API:CHANNELS_URL = RCMS_ROOT + /customer/%s/channelsCUSTOMER_URL = RCMS_ROOT + /customer/%sDEVICES_URL = RCMS_ROOT + /channel/%s/flexicacheDEVICES_FIRSTLAYER_URL = RCMS_ROOT + /channel/%s/flexicache/firstlayerCHANNELNAME = RCMS_ROOT + /channelsByName?channelName=%sDEVICE_STATUS_URL = RCMS_ROOT + /device/name/%s/statusDEVICE_BU_DEPARTMENT = RCMS_ROOT + /device/%sRcms 用户，频道，设备信息：2014-11-4类总数有效的非TRANSFER用户58114502频道6259438718 （实：38506）设备25651Portal 用户69276927-1220=？5737Portal频道2 目前问题： 1、首次 从缓存 读取，需要去rcms 系统 获得数据，cache 过期时间是10分钟， 这个频率很高，对rcms 系统压力很大，对刷新系统响应时间有很大影响 2、刷新系统使用 redis的存储是简单的key：json串，没有很好使用redis的功能 目前redis里面 三个 cache结构,只是简单的key-value，没有使用 redis 的 机制3、初始化,如何得到所有用户？ 4、rcms 的设备变更：设备不可用了，缓存如何更新？5、目前接口合并：CUSTOMER_URL 和 CHANNELS_URL 这两个接口是否可以合并DEVICES_URL 和 DEVICES_FIRSTLAYER_URL 这两个接口是否可以合并3 初步方案：方案一、第一步：刷新系统做一次初始化cache（目前，每10分钟过去cache 清空），设置cache 不过期，第二步：rcms系统数据有变化 ，rcms系统 根据刷新系统所提供的接口 通知刷新系统，变化的有以下这些关系包括：刷新系统根据rcms 推送内容更新cache 0、获取所有用户的信息，在初始化 这一步，如果用户有删除或增加，可以通知刷新系统。1、customer 和 channel 关系的变化：channel的增加，修改，删除等2、channel 和 device 关系的变化：channel对应的device的增加，修改，删除等3、channel 和 firstlayer 关系的变化 ：channel对应的device的增加，修改，删除等NOTE： 需要和rcms 沟通了解 能给什么数据？有哪些变化场景？比如是细化到关系变化涉及的对象id，还是只能通知到是什么类型的对象变化。 讨论后，初步定rcms接口：1、 设备状态变化 设置组变化：增删设备， 设备信息: 接口:用http，数据协议格式如下： oper_type_add:dev_ids: , channel_codes:,oper_type_del: dev_ids: , channel_codes:, oper_type_update:dev_ids: , channel_codes:, 2、 频道状态变化 转出：test/transfer/COMMERCIAL 频道所属客户变更 接口:用http，数据协议格式如下： oper_type_add:user_names:, channel_codes:,oper_type_del: user_names: , channel_codes:, oper_type_update:user_names_old: , user_names_cur:,channel_codes:, 第三步：重新 设计 redis 的 数据结构：发挥内存数据库的特点，读取性能的优化功能上，保证数据更新，查询可用，比如device和channel的互相更新；性能上利用redis的特性。redis缓存结构缓存名称采用存储结构：key：hash类型，即: key:field1：value1，field2：value2，field3：value3key描述字段：value 样例用户信息(key_value)结构userinfo_usernameuserinfo: code: 2922, companyName: , enable: true, name: sina_t, password: MTE3YjU2ZTlhNmNl, userState: COMMERCIAL,用户+频道（hashkeyvalue）chnls_by_【user_name】 15043:billingCode: 7438, channelState: TRANSFER, code: 15043, customerCode: 2922, customerName: sina_t, multilayer: true, name: , productCode: 9010100000002, transferTime: , channel_code2:, channel_code3:频道+设备devices_by_【channel_code】 CNC-HQ-a-3S1: firstLayer: false, host: 42, name: CNC-HQ-a-3S1, port: 21108, serialNumber: 060105a3S1, status: OPEN , : 频道+firstlayer设备Firstdevices_【channel_code】 CNC-HQ-3S1: firstLayer: false, host: 42, name: CNC-HQ-a-3S1, port: 21108, serialNumber: 060105a3S1, status: OPEN , : Portal上的用户+频道（hashkeyvalue）mongodb表结构描述类型cache_user_channelsusername用户名userinfo用户信息channels频道列表,.cache_channel_deviceschannel_code频道编码devices设备列表firstLayer: false/true,.,.cache_channel_firstlayer_deviceschannel_code频道编码devices设备列表,.cache_user_channels_portalusername用户名userinfo用户信息channels频道列表,.第四步：重构bermuda代码: rcmsapi.py 及 对缓存使用的代码方案二、如果rcms接口不能及时提供，采用mongodb缓存rcms数据方案，包括若干类及如下三个连接程序：程序1：起一个定时任务定时更新mongodb数据（比如每10分钟更新一次）程序2：比较和redis缓存数据，如果有需要更新，通知redis，其中数据接口和rcms交互接口一致。程序3：接收数据变化通知，根据数据变化内容，更新redis，保证代码可复用。缺点： （不能保证实时同步）redisClient程序3MongodbRCMS程序1程序2 4 详细实现目前版本，采用方案二：类图：数据结构数据结构包括redis和mongo的数据结构，都采用方案一中拟定的数据流图问题及场景：1. Case1：在更新redis 过程中 ，会出现 redis和mongodb的数据不一致，即并非所有记录都同步到redis 问题：跟踪结果：在同步到redis的时间点，从mongodb中获得的记录数 和 最终 记录数 是不一致。如下所示：notify_redis_update channels been changed nums:4054 应为 4076notify_redis_update devices been changed nums:27649 应为；34590notify_redis_update first device been changed nums:11104 应为 12959分析原因：由于没有事务完整性保证， 而且mongodb 延迟和一致性不能保证目前方案：可以采用，同步 一次 mongodb ， 多次 刷新 redis ，或者 延迟 刷新 redis或者：同步mongodb，同时，同步redis，不用再经过mongodb的更新2. Case2：Rcms 同步一次，时间20m, 使用 多线程 导致 rcms 系统 服务停止目前方案：全量更新 导致 对rcms 压力过大，采用 统计昨天用户+不在缓存中的用户，作为定时刷新的依据3. Case3：刷新系统从portal 根据用户 获得 channel时， businesses，如果里面有多个business，每个都有，channels，这个从业务上如何解释呢 目前方案： 遍历所有的productcode对应的channels4. Case4按前一日的用户刷新，今天缓存，如果今天用户访问和前一日的用户不同，导致用户缓存信息不是最新的：目前方案：1.全量 单独起个 进程，只刷新到mongo里面了2.定时刷新 ： 时间间隔为5分钟，测试，观察：大概到1000个用户时，在5分钟，rcms能否处理完成更新用户修改为：“前5天使用更新的用户“ 在统计完以后 一次性