优大网

kafka命令大全

https://www.orchome.com/454

管理

## 创建主题(4个分区,2个副本)
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 2 --partitions 4 --topic test

查询

## 查询集群描述
bin/kafka-topics.sh --describe --zookeeper 

## topic列表查询
bin/kafka-topics.sh --zookeeper 127.0.0.1:2181 --list

## topic列表查询(支持0.9版本+)
bin/kafka-topics.sh --list --bootstrap-server localhost:9092

## 新消费者列表查询(支持0.9版本+)
bin/kafka-consumer-groups.sh --new-consumer --bootstrap-server localhost:9092 --list

## 新消费者列表查询(支持0.10版本+)
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --list

## 显示某个消费组的消费详情(仅支持offset存储在zookeeper上的)
bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper localhost:2181 --group test

## 显示某个消费组的消费详情(0.9版本 - 0.10.1.0 之前)
bin/kafka-consumer-groups.sh --new-consumer --bootstrap-server localhost:9092 --describe --group test-consumer-group

## 显示某个消费组的消费详情(0.10.1.0版本+)
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

发送和消费

## 生产者
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

## 消费者
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test

## 新生产者(支持0.9版本+)
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test --producer.config config/producer.properties

## 新消费者(支持0.9版本+)
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --new-consumer --from-beginning --consumer.config config/consumer.properties

## 高级点的用法
bin/kafka-simple-consumer-shell.sh --brist localhost:9092 --topic test --partition 0 --offset 1234  --max-messages 10

平衡leader

bin/kafka-preferred-replica-election.sh --zookeeper zk_host:port/chroot

kafka自带压测命令

bin/kafka-producer-perf-test.sh --topic test --num-records 100 --record-size 1 --throughput 100  --producer-props bootstrap.servers=localhost:9092

分区扩容

bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic topic1 --partitions 2

迁移分区

  1. 创建规则json cat > increase-replication-factor.json {"version":1, "partitions":[ {"topic":"__consumer_offsets","partition":0,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":1,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":2,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":3,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":4,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":5,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":6,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":7,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":8,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":9,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":10,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":11,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":12,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":13,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":14,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":15,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":16,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":17,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":18,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":19,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":20,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":21,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":22,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":23,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":24,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":25,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":26,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":27,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":28,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":29,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":30,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":31,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":32,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":33,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":34,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":35,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":36,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":37,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":38,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":39,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":40,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":41,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":42,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":43,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":44,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":45,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":46,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":47,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":48,"replicas":[0,1]}, {"topic":"__consumer_offsets","partition":49,"replicas":[0,1]}] }
  2. 执行 bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file increase-replication-factor.json --execute
  3. 验证 bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file increase-replication-factor.json --verify

Flowable开发–核心数据库表(七)

一、数据模型设计

  1. 清单
数据表分类描述
ACT_GE_*通用数据表
ACT_RE_*流程定义存储表
ACT_ID_*身份信息表
ACT_RU_*运行时数据库表
ACT_HI_*历史数据库表
  1. 通用数据库
数据表描述
ACT_GE_PROPERTY属性表(保存流程引擎的kv键值属性)–PropertyEntityImpl
ACT_GE_BTYEARRAY资源表(存储流程定义相关的资源)–ByteArrayEntityImpl
  1. 流程定义存储表
数据表描述
ACT_RE_DEPLOYMENT流程部署表–DeploymentEntityImpl
ACT_RE_PROCDEF流程定义信息表–ProcessDefinitionEntityImpl
ACT_RE_MODEL模型信息表(用于Web设计器)–ModelEntityImpl
ACT_PROCDEF_INFO流程定义动态改变信息表–ProcessDefinitionInfoEntityImpl
  1. 身份数据表
数据表描述
ACT_ID_USER用户基本信息表–UserEntityImpl
ACT_ID_INFO用户扩展表–IdentityInfoEntityImpl
ACT_ID_GROUP群组表(用于Web设计器)–GroupEntityImpl
ACT_ID_MEMBERSHIP户与群主关系表–MemberShipEntityImpl
ACT_ID_BYTEARRAY二进制数据表(flowable)–
ACT_ID_PRIV权限表(flowable)–
ACT_ID_PRIV_MAPPING用户或组权限关系表(flowable)–
ACT_ID_PROPERTY属性表(flowable)–
ACT_ID_TOKEN系统登录日志表(flowable)–
  1. 运行时流程数据表
数据表描述
ACT_RU_EXECUTION流程实例与分支执行表–ExecutionEntityImpl
ACT_RU_TASK用户任务表–TaskEntityImpl
ACT_RU_VARIABLE变量信息–VariableInstanceEntityImpl
ACT_RU_IDENTITYLINK参与者相关信息表–IdentityLinkEntityImpl
ACT_RU_EVENT_SUBSCR事件订阅表–EventSubscriptionEntityImpl
ACT_RU_JOB作业表–JobEntityImpl
ACT_RU_TIMER_JOB定时器表–TimerJobEntityImpl
ACT_RU_SUSPENDED_JOB暂停作业表–SuspendedJobEntityImpl
ACT_RU_DEADLETTER_JOB死信表–DeadLetterJobEntityImpl
ACT_RU_HISTORY_JOB历史作业表(flowable)–
  1. 历史流程数据表
数据表描述
ACT_HI_PROCINST历史流程实例表–HistoricProcessInstanceEntityImpl
ACT_HI_ACTINST历史节点信息表–HistoricActivityInstanceEntityImpl
ACT_HI_TASKINST历史任务表–HistoricTaskInstanceEntityImpl
ACT_HI_VARINST历史变量–HistoricVariableInstanceEntityImpl
ACT_HI_IDENTITYLINK历史参与者表–HistoricIdentityLinkEntityImpl
ACT_HI_DETAIL历史的流程运行中的细节信息–HistoricDetailEntityImpl
ACT_HI_ATTACHMENT附件表–AttachmentEntityImpl
ACT_HI_COMMENT评论表–CommentEntityImpl
ACT_EVT_LOG事件日志表–EventLogEntryEntityImpl

二、表结构

  1. 通用类表

act_ge_property(全局配置文件)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
NAME_名称NOvarchar64PRIschema.version schema.history next.dbid
VALUE_NULLYESvarchar3005.* create(5.*)
REV_版本号NULLYESintNULLversion

注:
1.全局参数, 默认三个参数next.dbid, IdGenerator区间, schema.history, 自动执行sql历史, schema.version, 当
前sql版本。
2.属性数据表。存储整个流程引擎级别的数据。

act_ge_bytearray(二进制文件)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
NAME_名称NULLYESvarchar255部署的文件名称,如:mail.bpmn、mail.png 、mail.bpmn20.xml
DEPLOYMENT_ID_部署IDNULLYESvarchar64ACT_RE_DEPLOYMENT
BYTES_字节(二进制数据)NULLYESlongblob4294967295
GENERATED_是否系统生成NULLYEStinyintNULL0为用户上传,1为系统自动生成, 比如系统会自动根据xml生成png

注:
1.用来保存部署文件的大文本数据
2.所有二进制内容都会保存在这个表里, 比如部署的process.bpmn20.xml, process.png, user.form, 附件, bean序列
化为二进制的流程变量。
act_ge_property属性数据表存储整个流程引擎级别的数据,初始化表结构时,会默认插入三条记录。
  1. 历史类表

act_hi_actinst(历史节点表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
PROC_DEF_ID_流程定义IDNULLNOvarchar64
PROC_INST_ID_流程实例IDNULLNOvarchar64MUL
ACT_ID_节点IDNULLNOvarchar255
TASK_ID_任务IDNULLYESvarchar64任务实例ID 其他节点类型实例ID在这里为空
CALL_PROC_INST_ID_调用外部的流程实例IDNULLYESvarchar64
ACT_NAME_节点名称NULLYESvarchar255
ACT_TYPE_节点类型NULLNOvarchar255如startEvent、userTask
ASSIGNEE_签收人NULLYESvarchar255经办人
START_TIME_开始时间NULLNOdatetimeNULLMUL
END_TIME_结束时间NULLYESdatetimeNULLMUL
DURATION_耗时NULLYESbigintNULL毫秒值
TENANT_ID_多租户YESvarchar255

注:
1. 历史活动信息。这里记录流程流转过的所有节点,与HI_TASKINST不同的是,taskinst只记录usertask内容。
2.  TENANT_ID 是后续才加入的多租户

act_hi_attachment(历史附件表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键IDNULLNOvarchar64PRI
REV_版本号NULLYESintNULLversion
USER_ID_用户IDNULLYESvarchar255
NAME_名称NULLYESvarchar255
DESCRIPTION_描述NULLYESvarchar4000
TYPE_类型NULLYESvarchar255
TASK_ID_任务IDNULLYESvarchar64
PROC_INST_ID_流程实例IDNULLYESvarchar64
URL_附件地址NULLYESvarchar4000附件的URL地址
CONTENT_ID_字节表IDNULLYESvarchar64ACT_GE_BYTEARRAY的ID
TIME_时间NULLYESdatetimeNULL

注:
1.存放历史流程相关的附件。
2.时间是后续版本加入

act_hi_comment(历史审批意见表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
TYPE_类型NULLYESvarchar255类型:event(事件) comment(意见)
TIME_时间NULLNOdatetimeNULL
USER_ID_用户IDNULLYESvarchar255
TASK_ID_任务IDNULLYESvarchar64
PROC_INST_ID_流程实例IDNULLYESvarchar64
ACTION_行为类型NULLYESvarchar255
MESSAGE_基本内容NULLYESvarchar4000用于存放流程产生的信息,比如审批意见
FULL_MSG_全部内容NULLYESlongblob4294967295附件

注:

  1. 存放历史流程的审批意见。
  2. 行为类型。值为下列内容中的一种:AddUserLink、DeleteUserLink、AddGroupLink、DeleteGroupLink、AddComment、AddAttachment、DeleteAttachment

act_hi_detail(历史详情信息表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
TYPE_类型NULLNOvarchar255类型: FormProperty, //表单 VariableUpdate //参数
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL
EXECUTION_ID_执行实例NULLYESvarchar64
TASK_ID_任务IDNULLYESvarchar64MUL
ACT_INST_ID_节点实例IDNULLYESvarchar64ACT_HI_ACTINST
NAME_名称NULLNOvarchar255MUL
VAR_TYPE_参数类型NULLYESvarchar255
REV_版本号NULLYESintNULLversion
TIME_时间戳NULLNOdatetimeNULLMUL创建时间
BYTEARRAY_ID_字节表IDNULLYESvarchar64ACT_GE_BYTEARRAY
DOUBLE_浮点值NULLYESdoubleNULL存储变量类型为Double
LONG_长整型NULLYESbigintNULL存储变量类型为long
TEXT_文本值NULLYESvarchar4000存储变量值类型为String
TEXT2_字符串NULLYESvarchar4000此处存储的是JPA持久化对象时,才会有值。此值为对象ID,jpa变量text存className,text2存id

注:
1.历史详情表:流程中产生的变量详细,包括控制流程流转的变量,业务表单中填写的流程需要用到的变量等。
2.参数类型: jpa-entity、boolean、bytes、serializable(可序列化)、自定义type(根据你自身配置)、CustomVariableType、date、double、integer、long、null、short、string

act_hi_identitylink(历史流程人员表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
NOvarchar64PRI
GROUP_ID_用户组IDNULLYESvarchar255
TYPE_类型NULLYESvarchar255类型,主要分为以下几种:assignee、candidate、owner、starter 、participant
USER_ID_用户IDNULLYESvarchar255MUL
TASK_ID_任务IDNULLYESvarchar64MUL
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL

注:

  1. 任务参与者数据表。主要存储当前节点参与者的信息。

act_hi_procinst(流程实例历史*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
PROC_INST_ID_流程实例IDNULLNOvarchar64UNI
BUSINESS_KEY_业务标识NULLYESvarchar255MUL业务主键,业务表单的ID
PROC_DEF_ID_流程实例IDNULLNOvarchar64
START_TIME_开始时间NULLNOdatetimeNULL
END_TIME_结束时间NULLYESdatetimeNULLMUL
DURATION_耗时NULLYESbigintNULL
START_USER_ID_流程发起人IDNULLYESvarchar255
START_ACT_ID_开始节点IDNULLYESvarchar255
END_ACT_ID_结束节点IDNULLYESvarchar255
SUPER_PROCESS_INSTANCE_ID_父流程实例IDNULLYESvarchar64
DELETE_REASON_删除原因NULLYESvarchar4000
TENANT_ID_租户IDYESvarchar255
NAME_名称NULLYESvarchar255

注:
1.核心表之一。
2.存放历史的流程实例。
3.设计历史流程实例表的初衷之一就是为了使得运行时库数据量尽可能小,效率最优。

act_hi_taskinst(历史任务流程实例信息*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
PROC_DEF_ID_流程实例IDNULLYESvarchar64
TASK_DEF_KEY_任务节点定义IDNULLYESvarchar255任务定义标识(环节ID)
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL
EXECUTION_ID_执行实例IDNULLYESvarchar64
NAME_任务名称NULLYESvarchar255
PARENT_TASK_ID_父任务节点IDNULLYESvarchar64
DESCRIPTION_描述NULLYESvarchar4000
OWNER_被代理人NULLYESvarchar255委托人(默认为空,只有在委托时才有值)
ASSIGNEE_经办人NULLYESvarchar255
START_TIME_开始时间NULLNOdatetimeNULL
CLAIM_TIME_签收时间NULLYESdatetimeNULL
END_TIME_结束时间NULLYESdatetimeNULL
DURATION_耗时NULLYESbigintNULL
DELETE_REASON_删除原因NULLYESvarchar4000删除原因(completed,deleted)
PRIORITY_优先级NULLYESintNULL
DUE_DATE_截止时间NULLYESdatetimeNULL过期时间,表明任务应在多长时间内完成
FORM_KEY_FORM表单的KEYNULLYESvarchar255desinger节点定义的 form_key属性
CATEGORY_分类NULLYESvarchar255
TENANT_ID_租户IDYESvarchar255

注:

1. 历史任务实例表。 
2. 存放已经办理的任务。 
3. CATEGORY和TNANT_ID是后续版本才加进来的。 

act_hi_varinst(历史变量表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL
EXECUTION_ID_执行实例IDNULLYESvarchar64
TASK_ID_任务IDNULLYESvarchar64MUL
NAME_名称NULLNOvarchar255MUL
VAR_TYPE_变量类型NULLYESvarchar100
REV_版本号NULLYESintNULLversion
BYTEARRAY_ID_字节流IDNULLYESvarchar64ACT_GE_BYTEARRAY
DOUBLE_浮点值NULLYESdoubleNULL存储DoubleType类型的数据
LONG_长整型NULLYESbigintNULL存储LongType类型的数据
TEXT_文本值NULLYESvarchar4000存储变量值类型为String,如此处存储持久化对象时,值jpa对象的class
TEXT2_文本值NULLYESvarchar4000
CREATE_TIME_创建时间NULLYESdatetimeNULL
LAST_UPDATED_TIME_最后更新时间NULLYESdatetimeNULL

注:

  1. 主要存放历史变量数据。

act_evt_log(事件日志)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
LOG_NR_主键NULLNObigintNULLPRI
TYPE_类型NULLYESvarchar64
PROC_DEF_ID_流程定义IDNULLYESvarchar64
PROC_INST_ID_流程实例IDNULLYESvarchar64
EXECUTION_ID_执行IDNULLYESvarchar64
TASK_ID_任务IDNULLYESvarchar64
TIME_STAMP_时间CURRENT_TIMESTAMP(3)NOtimestampNULL
USER_ID_用户IDNULLYESvarchar255
DATA_数据NULLYESlongblob4294967295
LOCK_OWNER_锁定节点NULLYESvarchar255
LOCK_TIME_锁定时间NULLYEStimestampNULL
IS_PROCESSED_是否正在执行0YEStinyintNULL

注:
1.事件日志表
2.事件日志, 默认不开启。
3.从Activiti 5.16开始,引入了(试验性)的事件记录机制。记录机制基于Activiti引擎的事件机制的一般用途,并默认禁用。其思想是,来源于引擎的事件会被捕获,并创建一个包含了所有事件数据(甚至更多)的映射,提供给
org.activiti.engine.impl.event.logger.EventFlusher,由它将这些数据刷入其他地方。默认情况下,使用简单的基于数据库的事件处理/刷入,会使用Jackson将上述映射序列化为JSON,并将其作为EventLogEntryEntity接口存入数据库。如果不使用事件记录,可以删除这个表。
4.配置启用事件日志:
processEngineConfiguration.setEnableDatabaseEventLogging(true);
5.运行时启用事件日志:
databaseEventLogger = new EventLogger(processEngineConfiguration.getClock());
runtimeService.addEventListener(databaseEventLogger);
6.可以扩展EventLogger类。如果默认的数据库记录不符合要求,需要覆盖createEventFlusher()方法返回一个org.activiti.engine.impl.event.logger.EventFlusher接口的实例。可以通过Activiti的
managementService.getEventLogEntries(startLogNr, size)?获取EventLogEntryEntity实例。
容易看出这个表中的数据可以通过JSON放入大数据NoSQL存储,例如MongoDB,Elastic Search,等等。
也容易看出这里使用的类
(org.activiti.engine.impl.event.logger.EventLogger/EventFlusher与许多其他 EventHandler类)是可插入的,可以按你的使用场景调整(例如不将JSON存入数据库,而是将其直接发送给一个队列或大数据存储)。
请注意这个事件记录机制是额外于Activiti的“传统”历史管理器的。尽管所有数据都在数据库表中,但并未对查询或快速恢复做优化。实际使用场景是末端审计并将其存入大数据存储。

用户身份类
act_id_group(用户组)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
NAME_名称NULLYESvarchar255
TYPE_类型NULLYESvarchar255

注:
1.Activiti自带的用户组表,用于组任务。

act_id_info(用户扩展信息表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
USER_ID_用户IDNULLYESvarchar64
TYPE_类型NULLYESvarchar64
KEY_属性名NULLYESvarchar255
VALUE_属性值NULLYESvarchar255
PASSWORD_密码NULLYESlongblob4294967295
PARENT_ID_父级IDNULLYESvarchar255

注:

act_id_membership( 用户与分组对应信息表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
USER_ID_用户IDNOvarchar64PRI(ACT_ID_USER)
GROUP_ID_用户组IDNOvarchar64PRI(ACT_ID_GROUP)

注:
1.用来保存用户的分组信息。

act_id_user(用户信息表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
FIRST_NULLYESvarchar255FIRST_NAME
LAST_NULLYESvarchar255LAST_NAME
EMAIL_邮箱NULLYESvarchar255
PWD_密码NULLYESvarchar255
PICTURE_ID_头像IDNULLYESvarchar64ACT_GE_BYTEARRAY

注:
1.Activiti用户信息表。

流程定义存储表

act_procdef_info(流程定义更新信息)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
PROC_DEF_ID_流程定义IDNULLNOvarchar64UNI(ACT_RE_PROCDEF)
REV_版本号NULLYESintNULLversion
INFO_JSON_ID_内容NULLYESvarchar64MUL(ACT_GE_BYTEARRAY)

注:
1.流程版本升级的数据。

act_re_deployment( 部署信息表*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
NAME_名称NULLYESvarchar255
CATEGORY_分类NULLYESvarchar255
TENANT_ID_租户IDYESvarchar255
DEPLOY_TIME_部署时间NULLYEStimestampNULL

注:
1. 部署流程定义时需要被持久化保存下来的信息。

act_re_model( 流程设计模型部署表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
REV_版本号NULLYESintNULLversion
NAME_名称NULLYESvarchar255
KEY_标识NULLYESvarchar255
CATEGORY_分类NULLYESvarchar255
CREATE_TIME_创建时间NULLYESimestampNULL
LAST_UPDATE_TIME_最后更新时间NULLYEStimestampNULL
VERSION_版本NULLYESintNULL
META_INFO_元数据NULLYESvarchar4000以json格式保存流程定义的信息
DEPLOYMENT_ID_部署IDNULLYESvarchar64MUL(ACT_RE_DEPLOYMENT)
EDITOR_SOURCE_VALUE_ID_二进制文件IDNULLYESvarchar64MUL(ACT_GE_BYTEARRAY)设计器原始信息
EDITOR_SOURCE_EXTRA_VALUE_ID_二进制文件IDNULLYESvarchar64MUL(ACT_GE_BYTEARRAY)设计器扩展信息
TENANT_ID_租户IDYESvarchar255

注:
1.该表是流程设计器设计流程模型保存的数据。

act_re_procdef(流程定义数据表*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
REV_版本号NULLYESintNULLversion
CATEGORY_分类NULLYESvarchar255流程定义的Namespace就是类别
NAME_名称NULLYESvarchar255
KEY_标识NULLNOvarchar255MUL
VERSION_版本NULLNOintNULL
DEPLOYMENT_ID_部署IDNULLYESvarchar64
RESOURCE_NAME_资源名称NULLYESvarchar4000流程bpmn文件名称
DGRM_RESOURCE_NAME_图片资源名称NULLYESvarchar4000
DESCRIPTION_描述NULLYESvarchar4000
HAS_START_FORM_KEY_拥有开始表单标识NULLYEStinyintNULLstart节点是否存在formKey 0否 1是
HAS_GRAPHICAL_NOTATION_拥有图形信息NULLYEStinyintNULL
SUSPENSION_STATE_挂起状态NULLYESintNULL暂停状态 1激活 2暂停
TENANT_ID_租户IDYESvarchar255

注:
1. 业务流程定义数据表。此表和ACT_RE_DEPLOYMENT是多对一的关系,即,一个部署的bar包里可能包含多个流程定义文件,每个流程定义文件都会有一条记录在ACT_REPROCDEF表内,每个流程定义的数据,都会对于ACT_GE_BYTEARRAY表内的一个资源文件和PNG图片文件。和ACT_GE_BYTEARRAY的关联是通过程序用ACT_GE_BYTEARRAY.NAME与ACT_RE_PROCDEF.NAME_完成的,在数据库表结构中没有体现。

运行时流程数据表
act_ru_event_subscr(事件订阅)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
REV_版本号NULLYESintNULLvarsion
EVENT_TYPE_事件类型NULLNOvarchar255
EVENT_NAME_事件名称NULLYESvarchar255
EXECUTION_ID_执行实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_INST_ID_流程实例IDNULLYESvarchar64
ACTIVITY_ID_节点IDNULLYESvarchar64
CONFIGURATION_配置NULLYESvarchar255MUL
CREATED_创建时间CURRENT_TIMESTAMP(3)NOtimestampNULL
PROC_DEF_ID_流程定义IDNULLYESvarchar64
TENANT_ID_租户IDYESvarchar255

注:
1.该表是后续版本加进来的。

act_ru_execution(运行时流程执行实例表*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULL
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
BUSINESS_KEY_业务标识NULLYESvarchar255MUL
PARENT_ID_父级IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_DEF_ID_流程定义IDNULLYESvarchar64MUL(ACT_RE_PROCDEF)
SUPER_EXEC_父流程实例中对应的执行NULLYESvarchar64MUL(ACT_RU_EXECUTION)
ACT_ID_节点IDNULLYESvarchar255
IS_ACTIVE_是否激活NULLYEStinyintNULL
IS_CONCURRENT_是否分支(并行)NULLYEStinyintNULL是否为并行(true/false)
IS_SCOPE_是否处于多实例或环 节嵌套状态NULLYEStinyintNULL
IS_EVENT_SCOPE_是否激活状态NULLYEStinyintNULL
SUSPENSION_STATE_挂起状态NULLYESintNULL暂停状态 1激活 2暂停
CACHED_ENT_STATE_缓存状态NULLYESintNULL缓存的状态, 1 事件 监听 2 人工任务 3 异步作业
TENANT_ID_租户IDYESvarchar255
NAME_名称NULLYESvarchar255
LOCK_TIME_锁定时间NULLYEStimestampNULL

注:
1.TENANT_ID、NAME、LOCK_TIME是后续版本加入的。

act_ru_identitylink( 运行时流程人员表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
GROUP_ID_用户组IDNULLYESvarchar255MUL
TYPE_类型NULLYESvarchar255
USER_ID_用户IDNULLYESvarchar255MUL
TASK_ID_任务IDNULLYESvarchar64MUL(ACT_RU_TASK)
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_DEF_ID_流程定义IDNULLYESvarchar64MUL(ACT_RE_PROCDEF)

注:
1.任务参与者数据表。主要存储当前节点参与者的信息。

act_ru_job(运行时定时任务数据表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
REV_版本号NULLYESintNULL
TYPE_类型NULLNOvarchar255
LOCK_EXP_TIME_锁定过期时间NULLYEStimestampNULL
LOCK_OWNER_挂起者NULLYESvarchar255
EXCLUSIVE_是否唯一NULLYEStinyintNULL
EXECUTION_ID_执行实例IDNULLYESvarchar64
PROCESS_INSTANCE_ID_流程实例IDNULLYESvarchar64
PROC_DEF_ID_流程定义IDNULLYESvarchar64
RETRIES_重试次数NULLYESintNULL
EXCEPTION_STACK_ID_异常堆栈NULLYESvarchar64MUL(ACT_GE_BYTEARRAY)
EXCEPTION_MSG_异常信息NULLYESvarchar4000
DUEDATE_截止时间NULLYEStimestampNULL
REPEAT_重复NULLYESvarchar255
HANDLER_TYPE_处理器类型NULLYESvarchar255
HANDLER_CFG_处理器配置NULLYESvarchar4000
TENANT_ID_租户IDYESvarchar255

注:
1.作业执行器数据。
2.需要启用JOB组件:JobExecutor 是管理一组线程的组件,这些线程用于触发定时器(包括后续的异步消息)。在单元测试场景下,使用多线程会很笨重。
因此API提供 ManagementService.createJobQuery 用于查询,以及 ManagementService.executeJob 用于执行作业。这样作业的执
行就可以在单元测试内部控制。为了避免作业执行器的干扰,可以将它关闭。
默认情况下, JobExecutor 在流程引擎启动时激活。当你不希望 JobExecutor 随流程引擎启动时,设置:
<property name=”jobExecutorActivate” value=”false” />
3.11. 启用异步执行器 Async executor activation
AsyncExecutor 是管理线程池的组件,这个线程池用于触发定时器与异步任务。
默认情况下,由于历史原因,当使用 JobExecutor 时, AsyncExecutor 不生效。然而我们建议使用新的 AsyncExecutor 代替
JobExecutor ,通过定义两个参数实现
<property name=”asyncExecutorEnabled” value=”true” />
<property name=”asyncExecutorActivate” value=”true” />
asyncExecutorEnabled参数用于启用异步执行器,代替老的作业执行器。 第二个参数asyncExecutorActivate命令Activiti引擎在启动时
启动异步执行器线程池。

act_ru_task( 运行时任务节点表*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NOvarchar64PRI
REV_版本号NULLYESintNULLversion
EXECUTION_ID_执行实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_DEF_ID_流程定义IDNULLYESvarchar64MUL(ACT_RE_PROCDEF)
NAME_名称NULLYESvarchar255
PARENT_TASK_ID_父任务IDNULLYESvarchar64
DESCRIPTION_描述NULLYESvarchar4000
TASK_DEF_KEY_人物定义标识NULLYESvarchar255
OWNER_被代理人NULLYESvarchar255(一般情况下为空,只有在委托时才有值)
ASSIGNEE_经办人NULLYESvarchar255签收人或者委托人
DELEGATION_委托状态NULLYESvarchar64委托状态 PENDING委托中,RESOLVED已处理
PRIORITY_优先级NULLYESintNULL
CREATE_TIME_创建时间NULLYEStimestampNULLMUL
DUE_DATE_截止时间NULLYESdatetimeNULL
CATEGORY_分类NULLYESvarchar255
SUSPENSION_STATE_挂起状态NULLYESintNULL暂停状态 1激活 2暂停
TENANT_ID_租户IDYESvarchar255
FORM_KEY_表单标识NULLYESvarchar255

注:
1.运行时任务数据表

act_ru_variable( 运行时流程变量数据表*核心表)

字段字段名称字段默认值是否允许为空数据类型字段长度备注
ID_主键NULLNOvarchar64PRI
REV_版本号NULLYESintNULLversion
TYPE_类型NULLNOvarchar255见备注
NAME_名称NULLNOvarchar255
EXECUTION_ID_执行实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
PROC_INST_ID_流程实例IDNULLYESvarchar64MUL(ACT_RU_EXECUTION)
TASK_ID_任务IDNULLYESvarchar64MUL(ACT_RU_TASK)
BYTEARRAY_ID_资源IDNULLYESvarchar64MUL(ACT_GE_BYTEARRAY)
DOUBLE_浮点值NULLYESdoubleNULL存储变量类型为Double
LONG_长整型NULLYESbigintNULL存储变量类型为long
TEXT_文本值NULLYESvarchar4000存储变量值类型为String 如此处存储持久化对象时,值jpa对象的class
TEXT2_文本值NULLYESvarchar4000此处存储的是JPA持久化对象时,才会有值。此值为对象ID

注:
1.运行时流程变量数据表。
2.类型:jpa-entity、boolean、bytes、serializable(可序列化)、自定义type(根据你自身配置)、
CustomVariableType、date、double、integer、long、null、short、string

作者:无剑_君
链接:https://www.jianshu.com/p/ccd017e9fd58
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

跑步运动员鞋带绑法

https://jingyan.baidu.com/article/acf728fd48859ef8e510a32d.html

方法/步骤

  1.  第一步是先解开你已经系好的鞋带,在如下图两边鞋带互相绕一圈,拉紧,成麻绳状。

     

    如何办了鞋带后不会松-跑步运动员鞋带绑法
  2. 第二步是将两边鞋带折起,交叉,如下图:

    如何办了鞋带后不会松-跑步运动员鞋带绑法
  3. 第三步是将一边折起的鞋带弯曲处下折,放在另一个鞋带上面,如下图:

    如何办了鞋带后不会松-跑步运动员鞋带绑法
  4. 第四步原理如同第三步,如下图:

    如何办了鞋带后不会松-跑步运动员鞋带绑法
  5.  第五步将两边鞋带分别穿过洞,如下图:

    如何办了鞋带后不会松-跑步运动员鞋带绑法
  6. 1.  第六步将穿过的两部鞋带拉紧,即可,如下图:

    如何办了鞋带后不会松-跑步运动员鞋带绑法

单点登录怎么实现?

一、单点登录简介

假设一个场景:公司内部有财务、OA、订单服务等各类相互独立的应用系统,员工张三对这些系统有操作权限,如果张三想要登录某个系统进行业务操作,那么他需要输入相应的账号与密码。想象一下,当公司内部有 100 个应用系统,张三是不是要输入 100 次用户名和密码进行登录,然后分别才能进行业务操作呢?显然这是很不好的体验,因此我们需要引入一个这样的机制:张三只要输入一次用户名和密码登录,成功登录后,他就可以访问财务系统、OA 系统、订单服务等系统。这就是单点登录。

1

单点登录的英文全称是 Single Sign On,简称是 SSO。它的意思是说用户只需要登录一次,就可以在个人权限范围内,访问所有相互信任应用的功能模块,不管整个应用群的内部有多么复杂,对用户而言,都是一个统一的整体。用户访问 Web 系统的整个应用群与访问单个系统一样,登录和注销分别只要一次就够了。举个简单的例子,你登录了百度网页之后,点击跳转到百度贴吧,这时可以发现你已经自动登录了百度贴吧。

二、我们的技术实现
2.5

SSO 的技术实现要想做好并不容易,我们认为需求优先级应该先是单点登录和单点注销功能,然后是应用接入的门槛,最后是数据安全性,安全性对于 SSO 也非常重要。SSO 的核心是认证中心,但要实现用户一次登录,到处访问的效果,技术实现需要建立在用户系统、认证中心、权限系统、企业门户的基础上,各职责如下:

  • 用户系统:负责用户名、密码等帐户信息管理,包括增加、修改、启用、停用用户帐号,同时为认证中心提供对用户名和密码的校验。
  • 认证中心:负责凭证 token 的生成、加密、颁发、验证、销毁、登入 Login、登出 Logout。用户只有拥有凭证并验证通过才能访问企业门户。
  • 权限系统:负责角色管理、资源设置、授权设置、鉴定权限,具体实现可参考 RBAC。权限系统可为企业门户提供用户权限范围内的导航。
  • 企业门户:作为应用系统的集成门户 (Portal),集成了多个应用系统的功能,为用户提供链接导航、用户信息和登出功能等。
 2.1、服务端功能实现
  • 登录认证:接收登录帐号信息,让用户系统验证用户的登录信息。
  • 凭证生成:创建授权凭证 token,生成的凭证一般包含用户帐号信息、过期时间等信息,它是一串加密的字符串,加密算法如 AES{凭证明文 +MD5 加信息},可采用 JWT 标准。
  • 凭证颁发:与 SSO 客户端通信,发送凭证给 SSO 客户端。
  • 凭证验证:接收并校验来自 SSO 客户端的凭证有效性,凭证验证包括算法验证和数据验证。
  • 凭证销毁与登出:接收来自 SSO 客户端的登出请求,记录并销毁凭证,跳转至登录页面。
 2.2、客户端功能实现
  • 1、请求拦截:拦截应用未登录请求,跳转至登录页面。
  • 2、获取凭证:接收并存储由 SSO 服务端发来的凭证,凭证存储的方式有 Cookie、Session、网址传参、Header 等。
  • 3、提交凭证验证:与 SSO 服务端通信,发出校验凭证有效性的请求。
  • 4、获取用户权限:获取该凭证的用户权限,并返回受保护资源给用户。
  • 5、凭证销毁与登出:销毁本地会话,然后跳转至登出页面。
 2.3、用户单点登录流程
3
  • 登录:将用户输入的用户名和密码发送至认证中心,然后认证中心调用用户系统来验证登录信息。
  • 生成并颁发凭证:通过登录信息的验证后,认证中心创建授权凭证 token,然后把这个授权凭证 token 返回给 SSO 客户端。SSO 客户端拿到这个 token,进行存储。在后续请求中,在 HTTP 请求数据中都得加上这个 token。
  • 凭证验证:SSO 客户端发送凭证 token 给认证中心,认证中心校验这个 token 的有效性。凭证验证有算法验证和数据验证,算法验证可在 SSO 客户端完成。
 2.4、用户访问流程和单点注销

4

以上是用户的访问流程,如果用户没有有效的凭证,认证中心将强制用户进入登录流程。对于单点注销,用户如果注销了应用群内的其中一个应用,那么全局 token 也会被销毁,应用群内的所有应用将不能再被访问。

 2.5、具体接入与集成
2.5

我们的应用接入与集成具体如下:

  • 1、用户系统:接入国内机票平台的用户系统,负责登录认证。
  • 2、权限系统:接入国内机票平台的权限系统。
  • 3、认证中心:负责生成并颁发凭证、销毁凭证,改造国内机票平台的登入、登出。
  • 4、凭证验证:在国内机票、国际机票应用系统中调用 SSO 客户端组件实现凭证的验证。
  • 5、企业门户:由国内机票平台、国际机票平台承担。
三、JWT 标准
3.0

JSON Web Token (JWT) 是目前应用最为广泛的 token 格式,是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准(RFC 7519)。该 token 设计紧凑且安全,特别适用于分布式站点的单点登录、API 网关等场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息。该 token 也可直接被用于认证,也可被加密。JWT 信息体由 3 部分构成:头 Header+ 载荷 Payload+ 签名 Signature,具体优点如下:

  • JWT 支持多种语言,C#、Java、JavaScript、Node.js、PHP 等很多语言都可以使用。
  • JWT 可以自身存储一些和业务逻辑有关的所必要的非敏感信息,因为有了 Payload 部分。
  • 利于传输,因为 JWT 的构成非常简单,字节占用很小。
  • 不需要在服务端保存会话信息,不仅省去服务端资源开销,而且使得应用易于扩展。
作者介绍

杨丽,拥有多年互联网应用系统研发经验,曾就职于古大集团,现任职中青易游的系统架构师,主要负责公司研发中心业务系统的架构设计以及新技术积累和培训。现阶段主要关注开源软件、软件架构、微服务以及大数据。

张辉清,10 多年的 IT 老兵,先后担任携程架构师、古大集团首席架构、中青易游 CTO 等职务,主导过两家公司的技术架构升级改造工作。现关注架构与工程效率,技术与业务的匹配与融合,技术价值与创新。

https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247487340&idx=1&sn=4063fdba487a860b8a576332c1ea3eb8&chksm=96c9b90ca1be301a985edbc1c2e340bdaf748364231636a33857233263ccdb847204451aae6b#rd

使用nginx lua实现网站统计中的数据收集

摘要: 网站数据统计分析工具是网站站长和运营人员经常使用的一种工具,比较常用的有谷歌分析、百度统计和腾讯分析等等。所有这些统计分析工具的第一步都是网站访问数据的收集。目前主流的数据收集方式基本都是基于javascript的。

网站数据统计分析工具是网站站长和运营人员经常使用的一种工具,比较常用的有谷歌分析百度统计腾讯分析等等。所有这些统计分析工具的第一步都是网站访问数据的收集。目前主流的数据收集方式基本都是基于javascript的。本文将简要分析这种数据收集的原理,并一步一步实际搭建一个实际的数据收集系统。

数据收集原理分析

简单来说,网站统计分析工具需要收集到用户浏览目标网站的行为(如打开某网页、点击某按钮、将商品加入购物车等)及行为附加数据(如某下单行为产生的订单金额等)。早期的网站统计往往只收集一种用户行为:页面的打开。而后用户在页面中的行为均无法收集。这种收集策略能满足基本的流量分析、来源分析、内容分析及访客属性等常用分析视角,但是,随着ajax技术的广泛使用及电子商务网站对于电子商务目标的统计分析的需求越来越强烈,这种传统的收集策略已经显得力不能及。

后来,Google在其产品谷歌分析中创新性的引入了可定制的数据收集脚本,用户通过谷歌分析定义好的可扩展接口,只需编写少量的javascript代码就可以实现自定义事件和自定义指标的跟踪和分析。目前百度统计、搜狗分析等产品均照搬了谷歌分析的模式。

其实说起来两种数据收集模式的基本原理和流程是一致的,只是后一种通过javascript收集到了更多的信息。下面看一下现在各种网站统计工具的数据收集基本原理。

流程概览

首先通过一幅图总体看一下数据收集的基本流程。

图1. 网站统计数据收集基本流程

首先,用户的行为会触发浏览器对被统计页面的一个http请求,这里姑且先认为行为就是打开网页。当网页被打开,页面中的埋点javascript片段会被执行,用过相关工具的朋友应该知道,一般网站统计工具都会要求用户在网页中加入一小段javascript代码,这个代码片段一般会动态创建一个script标签,并将src指向一个单独的js文件,此时这个单独的js文件(图1中绿色节点)会被浏览器请求到并执行,这个js往往就是真正的数据收集脚本。数据收集完成后,js会请求一个后端的数据收集脚本(图1中的backend),这个脚本一般是一个伪装成图片的动态脚本程序,可能由php、python或其它服务端语言编写,js会将收集到的数据通过http参数的方式传递给后端脚本,后端脚本解析参数并按固定格式记录到访问日志,同时可能会在http响应中给客户端种植一些用于追踪的cookie。

上面是一个数据收集的大概流程,下面以谷歌分析为例,对每一个阶段进行一个相对详细的分析。

埋点脚本执行阶段

若要使用谷歌分析(以下简称GA),需要在页面中插入一段它提供的javascript片段,这个片段往往被称为埋点代码。下面是我的博客中所放置的谷歌分析埋点代码截图:

图2. 谷歌分析埋点代码

其中_gaq是GA的的全局数组,用于放置各种配置,其中每一条配置的格式为:

  1. _gaq.push([‘Action’, ‘param1’, ‘param2’, …]);

Action指定配置动作,后面是相关的参数列表。GA给的默认埋点代码会给出两条预置配置,_setAccount用于设置网站标识ID,这个标识ID是在注册GA时分配的。_trackPageview告诉GA跟踪一次页面访问。更多配置请参考:https://developers.google.com/analytics/devguides/collection/gajs/。实际上,这个_gaq是被当做一个FIFO队列来用的,配置代码不必出现在埋点代码之前,具体请参考上述链接的说明。

就本文来说,_gaq的机制不是重点,重点是后面匿名函数的代码,这才是埋点代码真正要做的。这段代码的主要目的就是引入一个外部的js文件(ga.js),方式是通过document.createElement方法创建一个script并根据协议(http或https)将src指向对应的ga.js,最后将这个element插入页面的dom树上。

注意ga.async = true的意思是异步调用外部js文件,即不阻塞浏览器的解析,待外部js下载完成后异步执行。这个属性是HTML5新引入的。

数据收集脚本执行阶段

数据收集脚本(ga.js)被请求后会被执行,这个脚本一般要做如下几件事:

1、通过浏览器内置javascript对象收集信息,如页面title(通过document.title)、referrer(上一跳url,通过document.referrer)、用户显示器分辨率(通过windows.screen)、cookie信息(通过document.cookie)等等一些信息。

2、解析_gaq收集配置信息。这里面可能会包括用户自定义的事件跟踪、业务数据(如电子商务网站的商品编号等)等。

3、将上面两步收集的数据按预定义格式解析并拼接。

4、请求一个后端脚本,将信息放在http request参数中携带给后端脚本。

这里唯一的问题是步骤4,javascript请求后端脚本常用的方法是ajax,但是ajax是不能跨域请求的。这里ga.js在被统计网站的域内执行,而后端脚本在另外的域(GA的后端统计脚本是http://www.google-analytics.com/__utm.gif),ajax行不通。一种通用的方法是js脚本创建一个Image对象,将Image对象的src属性指向后端脚本并携带参数,此时即实现了跨域请求后端。这也是后端脚本为什么通常伪装成gif文件的原因。通过http抓包可以看到ga.js对__utm.gif的请求:

图3. 后端脚本请求的http包

可以看到ga.js在请求__utm.gif时带了很多信息,例如utmsr=1280×1024是屏幕分辨率,utmac=UA-35712773-1是_gaq中解析出的我的GA标识ID等等。

值得注意的是,__utm.gif未必只会在埋点代码执行时被请求,如果用_trackEvent配置了事件跟踪,则在事件发生时也会请求这个脚本。

由于ga.js经过了压缩和混淆,可读性很差,我们就不分析了,具体后面实现阶段我会实现一个功能类似的脚本。

后端脚本执行阶段

GA的__utm.gif是一个伪装成gif的脚本。这种后端脚本一般要完成以下几件事情:

1、解析http请求参数的到信息。

2、从服务器(WebServer)中获取一些客户端无法获取的信息,如访客ip等。

3、将信息按格式写入log。

5、生成一副1×1的空gif图片作为响应内容并将响应头的Content-type设为image/gif。

5、在响应头中通过Set-cookie设置一些需要的cookie信息。

之所以要设置cookie是因为如果要跟踪唯一访客,通常做法是如果在请求时发现客户端没有指定的跟踪cookie,则根据规则生成一个全局唯一的cookie并种植给用户,否则Set-cookie中放置获取到的跟踪cookie以保持同一用户cookie不变(见图4)。

图4. 通过cookie跟踪唯一用户的原理

这种做法虽然不是完美的(例如用户清掉cookie或更换浏览器会被认为是两个用户),但是是目前被广泛使用的手段。注意,如果没有跨站跟踪同一用户的需求,可以通过js将cookie种植在被统计站点的域下(GA是这么做的),如果要全网统一定位,则通过后端脚本种植在服务端域下(我们待会的实现会这么做)。

系统的设计实现

根据上述原理,我自己搭建了一个访问日志收集系统。总体来说,搭建这个系统要做如下的事:

图5. 访问数据收集系统工作分解

下面详述每一步的实现。我将这个系统叫做MyAnalytics。

确定收集的信息

为了简单起见,我不打算实现GA的完整数据收集模型,而是收集以下信息。

名称 途径 备注
访问时间 web server Nginx $msec
IP web server Nginx $remote_addr
域名 javascript document.domain
URL javascript document.URL
页面标题 javascript document.title
分辨率 javascript window.screen.height & width
颜色深度 javascript window.screen.colorDepth
Referrer javascript document.referrer
浏览客户端 web server Nginx $http_user_agent
客户端语言 javascript navigator.language
访客标识 cookie
网站标识 javascript 自定义对象

埋点代码

埋点代码我将借鉴GA的模式,但是目前不会将配置对象作为一个FIFO队列用。一个埋点代码的模板如下:

  1. <script type=”text/javascript”>// <![CDATA[
  2. var _maq = _maq || []; _maq.push([‘_setAccount’, ‘网站标识’]); (function() { var ma = document.createElement(‘script’); ma.type = ‘text/javascript’; ma.async = true; ma.src = (‘https:’ == document.location.protocol ? ‘https://analytics’ : ‘http://analytics’) + ‘.codinglabs.org/ma.js’; var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ma, s); })();
  3. // ]]></script>

这里我启用了二级域名analytics.codinglabs.org,统计脚本的名称为ma.js。当然这里有一点小问题,因为我并没有https的服务器,所以如果一个https站点部署了代码会有问题,不过这里我们先忽略吧。

前端统计脚本

我写了一个不是很完善但能完成基本工作的统计脚本ma.js:

  1. (function () {
  2. var params = {};
  3. //Document对象数据
  4. if(document) {
  5. params.domain = document.domain || ”;
  6. params.url = document.URL || ”;
  7. params.title = document.title || ”;
  8. params.referrer = document.referrer || ”;
  9. }
  10. //Window对象数据
  11. if(window &amp;&amp; window.screen) {
  12. params.sh = window.screen.height || 0;
  13. params.sw = window.screen.width || 0;
  14. params.cd = window.screen.colorDepth || 0;
  15. }
  16. //navigator对象数据
  17. if(navigator) {
  18. params.lang = navigator.language || ”;
  19. }
  20. //解析_maq配置
  21. if(_maq) {
  22. for(var i in _maq) {
  23. switch(_maq[i][0]) {
  24. case ‘_setAccount’:
  25. params.account = _maq[i][1];
  26. break;
  27. default:
  28. break;
  29. }
  30. }
  31. }
  32. //拼接参数串
  33. var args = ”;
  34. for(var i in params) {
  35. if(args != ”) {
  36. args += ‘&amp;’;
  37. }
  38. args += i + ‘=’ + encodeURIComponent(params[i]);
  39. }
  40. //通过Image对象请求后端脚本
  41. var img = new Image(1, 1);
  42. img.src = ‘http://analytics.codinglabs.org/1.gif?’ + args;
  43. })();

整个脚本放在匿名函数里,确保不会污染全局环境。功能在原理一节已经说明,不再赘述。其中1.gif是后端脚本。

日志格式

日志采用每行一条记录的方式,采用不可见字符^A(ascii码0x01,Linux下可通过ctrl + v ctrl + a输入,下文均用“^A”表示不可见字符0x01),具体格式如下:

时间^AIP^A域名^AURL^A页面标题^AReferrer^A分辨率高^A分辨率宽^A颜色深度^A语言^A客户端信息^A用户标识^A网站标识

后端脚本

为了简单和效率考虑,我打算直接使用nginx的access_log做日志收集,不过有个问题就是nginx配置本身的逻辑表达能力有限,所以我选用了OpenResty做这个事情。OpenResty是一个基于Nginx扩展出的高性能应用开发平台,内部集成了诸多有用的模块,其中的核心是通过ngx_lua模块集成了Lua,从而在nginx配置文件中可以通过Lua来表述业务。关于这个平台我这里不做过多介绍,感兴趣的同学可以参考其官方网站http://openresty.org/,或者这里有其作者章亦春(agentzh)做的一个非常有爱的介绍OpenResty的slide:http://agentzh.org/misc/slides/ngx-openresty-ecosystem/,关于ngx_lua可以参考:https://github.com/chaoslawful/lua-nginx-module

首先,需要在nginx的配置文件中定义日志格式:

  1. log_format tick “$msec^A$remote_addr^A$u_domain^A$u_url^A$u_title^A$u_referrer^A$u_sh^A$u_sw^A$u_cd^A$u_lang^A$http_user_agent^A$u_utrace^A$u_account”;

注意这里以u_开头的是我们待会会自己定义的变量,其它的是nginx内置变量。

然后是核心的两个location:

  1. location /1.gif {
  2. #伪装成gif文件
  3. default_type image/gif;
  4. #本身关闭access_log,通过subrequest记录log
  5. access_log off;
  6. access_by_lua ”
  7. — 用户跟踪cookie名为__utrace
  8. local uid = ngx.var.cookie___utrace
  9. if not uid then
  10. — 如果没有则生成一个跟踪cookie,算法为md5(时间戳+IP+客户端信息)
  11. uid = ngx.md5(ngx.now() .. ngx.var.remote_addr .. ngx.var.http_user_agent)
  12. end
  13. ngx.header[‘Set-Cookie’] = {‘__utrace=’ .. uid .. ‘; path=/’}
  14. if ngx.var.arg_domain then
  15. — 通过subrequest到/i-log记录日志,将参数和用户跟踪cookie带过去
  16. ngx.location.capture(‘/i-log?’ .. ngx.var.args .. ‘&utrace=’ .. uid)
  17. end
  18. “;
  19. #此请求不缓存
  20. add_header Expires “Fri, 01 Jan 1980 00:00:00 GMT”;
  21. add_header Pragma “no-cache”;
  22. add_header Cache-Control “no-cache, max-age=0, must-revalidate”;
  23. #返回一个1×1的空gif图片
  24. empty_gif;
  25. }
  26. location /i-log {
  27. #内部location,不允许外部直接访问
  28. internal;
  29. #设置变量,注意需要unescape
  30. set_unescape_uri $u_domain $arg_domain;
  31. set_unescape_uri $u_url $arg_url;
  32. set_unescape_uri $u_title $arg_title;
  33. set_unescape_uri $u_referrer $arg_referrer;
  34. set_unescape_uri $u_sh $arg_sh;
  35. set_unescape_uri $u_sw $arg_sw;
  36. set_unescape_uri $u_cd $arg_cd;
  37. set_unescape_uri $u_lang $arg_lang;
  38. set_unescape_uri $u_utrace $arg_utrace;
  39. set_unescape_uri $u_account $arg_account;
  40. #打开日志
  41. log_subrequest on;
  42. #记录日志到ma.log,实际应用中最好加buffer,格式为tick
  43. access_log /path/to/logs/directory/ma.log tick;
  44. #输出空字符串
  45. echo ”;
  46. }

要完全解释这段脚本的每一个细节有点超出本文的范围,而且用到了诸多第三方ngxin模块(全都包含在OpenResty中了),重点的地方我都用注释标出来了,可以不用完全理解每一行的意义,只要大约知道这个配置完成了我们在原理一节提到的后端逻辑就可以了。

日志轮转

真正的日志收集系统访问日志会非常多,时间一长文件变得很大,而且日志放在一个文件不便于管理。所以通常要按时间段将日志切分,例如每天或每小时切分一个日志。我这里为了效果明显,每一小时切分一个日志。我是通过crontab定时调用一个shell脚本实现的,shell脚本如下:

  1. _prefix=”/path/to/nginx”
  2. time=`date +%Y%m%d%H`
  3. mv ${_prefix}/logs/ma.log ${_prefix}/logs/ma/ma-${time}.log
  4. kill -USR1 `cat ${_prefix}/logs/nginx.pid`

这个脚本将ma.log移动到指定文件夹并重命名为ma-{yyyymmddhh}.log,然后向nginx发送USR1信号令其重新打开日志文件。

然后再/etc/crontab里加入一行:

  1. 59 * * * * root /path/to/directory/rotatelog.sh

在每个小时的59分启动这个脚本进行日志轮转操作。

测试

下面可以测试这个系统是否能正常运行了。我昨天就在我的博客中埋了相关的点,通过http抓包可以看到ma.js和1.gif已经被正确请求:

图6. http包分析ma.js和1.gif的请求

同时可以看一下1.gif的请求参数:

图7. 1.gif的请求参数

相关信息确实也放在了请求参数中。

然后我tail打开日志文件,然后刷新一下页面,因为没有设access log buffer, 我立即得到了一条新日志:

  1. 1351060731.360^A0.0.0.0^Awww.codinglabs.org^Ahttp://www.codinglabs.org/^ACodingLabs^A^A1024^A1280^A24^Azh-CN^AMozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4^A4d612be64366768d32e623d594e82678^AU-1-1

注意实际上原日志中的^A是不可见的,这里我用可见的^A替换为方便阅读,另外IP由于涉及隐私我替换为了0.0.0.0。

看一眼日志轮转目录,由于我之前已经埋了点,所以已经生成了很多轮转文件:

图8. 轮转日志

关于分析

通过上面的分析和开发可以大致理解一个网站统计的日志收集系统是如何工作的。有了这些日志,就可以进行后续的分析了。本文只注重日志收集,所以不会写太多关于分析的东西。

注意,原始日志最好尽量多的保留信息而不要做过多过滤和处理。例如上面的MyAnalytics保留了毫秒级时间戳而不是格式化后的时间,时间的格式化是后面的系统做的事而不是日志收集系统的责任。后面的系统根据原始日志可以分析出很多东西,例如通过IP库可以定位访问者的地域、user agent中可以得到访问者的操作系统、浏览器等信息,再结合复杂的分析模型,就可以做流量、来源、访客、地域、路径等分析了。当然,一般不会直接对原始日志分析,而是会将其清洗格式化后转存到其它地方,如MySQL或HBase中再做分析。

分析部分的工作有很多开源的基础设施可以使用,例如实时分析可以使用Storm,而离线分析可以使用Hadoop。当然,在日志比较小的情况下,也可以通过shell命令做一些简单的分析,例如,下面三条命令可以分别得出我的博客在今天上午8点到9点的访问量(PV),访客数(UV)和独立IP数(IP):

  1. awk -F^A ‘{print $1}’ ma-2012102409.log | wc -l
  2. awk -F^A ‘{print $12}’ ma-2012102409.log | uniq | wc -l
  3. awk -F^A ‘{print $2}’ ma-2012102409.log | uniq | wc -l

其它好玩的东西朋友们可以慢慢挖掘。

参考

GA的开发者文档:https://developers.google.com/analytics/devguides/collection/gajs/

一篇关于实现nginx收日志的文章:http://blog.linezing.com/2011/11/%E4%BD%BF%E7%94%A8nginx%E8%AE%B0%E6%97%A5%E5%BF%97

关于Nginx可以参考:http://wiki.nginx.org/Main

OpenResty的官方网站为:http://openresty.org

ngx_lua模块可参考:https://github.com/chaoslawful/lua-nginx-module

本文http抓包使用Chrome浏览器开发者工具,绘制思维导图使用Xmind,流程和结构图使用Tikz PGF
转自:http://blog.codinglabs.org/articles/how-web-analytics-data-collection-system-work.html

一文总结学习 Python 的 14 张思维导图

https://blog.csdn.net/csdnnews/article/details/78248699

本文主要涵盖了 Python 编程的核心知识(暂不包括标准库及第三方库)。

按顺序依次展示了以下内容的一系列思维导图:基础知识,数据类型(数字,字符串,列表,元组,字典,集合),条件&循环,文件对象,错误&异常,函数,模块,面向对象编程。

14 张思维导图

基础知识

数据类型

序列

字符串

列表 & 元组

字典 & 集合

条件 & 循环

文件对象

错误 & 异常

函数

模块

面向对象编程

作者:ZY,来源:ZOE | 数林觅风 ,解释权归原作者所有,侵删。

浅谈物联网的关键技术和难点

物联网中的核心关键技术

核心关键技术主要有RFID技术、传感器技术、无线网络技术、人工智能技术、云计算技术等。

   1、RFID技术

是物联网中“让物品开口说话”的关键技术,物联网中RFID标签上存着规范而具有互通性的信息,通过无线数据通信网络把他们自动采集到中央信息系统中实现物品的识别。

 

 

    2、传感器技术

在物联网中传感器主要负责接收物品“讲话”的内容。传感器技术是从自然信源获取信息并对获取的信息进行处理、变换、识别的一门多学科交叉的现代科学与工程技术,它涉及传感器、信息处理和识别的规划设计、开发、制造、测试、应用及评价改进活动等内容。

 3、无线网络技术

物联网中物品要与人无障碍地交流,必然离不开高速、可进行大批量数据传输的无线网络。无线网络既包括允许用户建立远距离无线连接的全球语音和数据网络,也包括近距离的蓝牙技术、红外技术和Zigbee技术。

 

 

    4、人工智能技术

人工智能是研究是计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考和规划等)的技术。在物联网中人工智能技术主要将物品“讲话”的内容进行分析,从而实现计算机自动处理。

 5、云计算技术

物联网的发展理离不开云计算技术的支持。物联网中的终端的计算和存储能力有限,云计算平台可以作为物联网的大脑,以实现对海量数据的存储和计算。

 

 

    物联网中的技术难点

 (1)数据安全问题

由于传感器数据采集频繁,基本可以说是随时在采集数据,数据安全必须重点考虑。

 (2)终端问题

物联网中的终端除了具有自己的功能外还有传感器和网络接入功能,且不同的行业千差万别,如何满足终端产品的多样化需求,对研究者和运营商都是一个巨大挑战。

想得却不可得 你奈人生何

想得却不可得 你奈人生何
该舍的舍不得 只顾著跟往事瞎扯
等你发现时间是贼了 它早已偷光你的选择

–李宗盛《给自己的歌》

« 较早的 文章

Copyright © 2020 优大网 浙ICP备13002865号-3

SITEMAP回到顶部 ↑