1.Ranger Plugin启动及运行过程

Ranger Plugin的启动及运行过程分为以下四步：

（1）每个插件集成RangerBasePlugin。

（2）RangerBasePlugin中开启策略刷新器PolicyRefresher。

（3）配置刷新时间间隔，如代码中的pollingIntervalMs变量所示，由ranger-*-audit.xml或ranger-*-security.xml配置文件中的ranger.plugin.hbase.policy.pollIntervalMs参数决定，默认为30秒。

（4）PolicyRefresher定时发送Rest请求到Ranger Admin中获取配置策略，如果配置策略有变动，则把新策略写入到本地临时json文件并更新缓存。

启动过程如下图所示：

可以看到，Ranger Plugin的运行时就是一个无限循环的处理线程。

2.策略同步

Ranger Plugin启动后，进入了一个无限循环的状态，每次循环都是一次策略加载和状态检测。根据源码，可得策略同步的流程，如下图所示：

策略同步默认根据service版本号(lastKnownVersion)来判断是否存在更新，进而根据service与policy的映射关系来获取更新后的策略信息，如果没有则不做任何处理；同时可以通过配置ranger.admin.supports.policy.deltas=true来实现通过策略变化进行增量更新，这种方式默认是关闭的，需要手动开启，通过直接读取policy_change_log表来读取增量策略。

缓存的json文件只有在RangerAdmin意外终止且plugin发生重启时候生效，其他情况并不会造成影响。admin终止之时策略不再更新而已。ranger本身是支持策略的导入导出的，如果遇到这种情况应该将备份的策略信息先导入到admin再重新安装。

3.策略加载过程

策略加载由PolicyRefresher完成，对应第一章节中PolicyRefresher中的内容。PolicyRefresher是一个Thread的扩展类，主要源码如下所示：

public void run() {
       ……
       while(true) {
              try {
                     Thread.sleep(pollingIntervalMs);
                     loadPolicy();
                     loadClusterHosts();
              } catch(Throwable excp) {
                     LOG.error("……", excp);
              }
       }
}

根据源代码，策略同步的方法可由下图表示。

由上图可以看出，过程中有缓存的设计，避免每次策略同步请求对数据库的访问，避免了高额的磁盘IO开销。