分布式缓存系统面临的问题

缓存一致性问题

1：缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时，写得尤为重要

2：有继承关系的缓存之间的一致性。为了尽量提高缓存命中率，缓存也是分层：全局缓存，二级缓存。他们是存在继承关系的。全局缓存可以有二级缓存来组成。

3：多个缓存副本之间的一致性。为了保证系统的高可用性，缓存系统背后往往会接两套存储系统（如memcache，redis等）

缓存穿透和缓存雪崩

上面有讲过

缓存数据的淘汰

缓存淘汰的策略有两种： 

(1) 定时去清理过期的缓存。

(2)当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂，具体用哪种方案，大家可以根据自己的应用场景来权衡。

1. 预估失效时间

2. 版本号（必须单调递增，时间戳是最好的选择）

3. 提供手动清理缓存的接口。

JBPM4工作流引擎描述

JPBM是JBOSS旗下的一个开源的基于hibernate的工作流引擎。工作流就是在日常生活中，我们一些常见的如请假流程、采购流程、入职流程，通俗的来讲就是一些在现实生活中的流程以信息化以程序的方式实现。

一个工作流首先需要进行流程定义，流程定义是由节点和跳转组成的，节点又可以称为环节、活动节点、活动环节，并且节点也可以分为两大类型：人工节点和自动节点，人工节点有start开始节点、end结束节点、task任务节点，自动节点有decision判断节点、fork分支节点、join聚合节点和state状态节点，并且一个流程有且只有一个开始节点，但可以有多个结束节点。

流程定义是静止的，它在运行状态时会转换成流程实例，一个流程定义可以对应多个流程实例。流程运行后，会产生两个文件，*.jdpl.xml文件和*.png图片文件，也会生成18张数据库表，常用且核心的表有JBPM4_LOB 存储表，主要存储xml文件和png图片、JBPM4_TASK 任务表、JBPM4_EXECUTION 流程实例表、JBPM4_VARIABLE变量表。

 

JBPM有五大核心类：

ProcessEngine：主要获取各种的Service

RepositoryService：主要发布流程定义

ExecutionService：主要操作流程实例

TaskService：主要操作人工服务

HistoryService：主要操作历史服务。

 

核心方法：

读取jbpm定义的文件生成zip包存到lob表中：createDeployment()

获取流程定义列表：createProcessDefinitionQuery

根据定义的key或id来启动流程实例：startProcessInstanceByKey(id)

获取待办任务列表：findPersonalTasks(userName)

完成指定任务列表：completeTask(*.getActivityId())

获取历史任务列表：createHistoryTaskQuery()

获取流程实例的ID：task.getExecutionId()

 

(了解的表)

JBPM4_HIST_ACTINST 流程活动(节点) 实例表

JBPM4_HIST_DETAIL 流程历史详细表

JBPM4_HIST_PROCINST 流程实例历史表

JBPM4_HIST_TASK 流程任务实例历史表

JBPM4_HIST_VAR 流程变量( 上下文) 历史表