Vertica简要

数据分析工作负载VS事务性工作负载
证明商业和技术可靠的大规模分布式数据库,支持ACID、有效存储PB级别数据的系统

分析数据库的架构,关注与C-Store不同的点
实施和部署的经验,为什么引入那些不同
现实世界的经验可以引导未来大规模数据分析系统研究的方向

2.背景
2.1.1设计目标:分析工作负载不是事务工作负载
事务工作负载:每秒事务数多,每个事务会影响少数几个元组,大部分的事务是增加一个新行或者修改部分已存在的列
分析工作负载:每秒事务数少,每个事务检查很多表中的元组,比如分析用户的行为,行处理每秒很多

数据量级的增加,即使是小公司

最初就是设计一个分布式数据库
1、新节点加入系统性能有线性的扩展。使用共享磁盘的架构也能获得这样的扩展,但这很快会成为系统的瓶颈
2、优化和执行的引擎避免大量的网络数据传输,以避免内部互联成为系统瓶颈
3、查询和加载数据每秒都会有很多,必须关注支持高插入,否则只能有限的应用,批量的加载应该很快而又不能影响并行的查询
4、操作可在线,管理和维护任务不应该停止或暂停查询
5、易于使用是一个明确的目标。用CPU换时间,形式上减少复杂的网络和磁盘设置,减少性能的调优,自动化的物理设计和管理

3数据模型
3.1 (列)计划
属性排序子集(经过编码和压缩并按某种次序排序和分割的纵列集合)
加载过程中自动维护
每个Projection都有自己的排序,数据是完全排序的
任意数量、带有不同排序的推算或表列的子集是被允许的,可针对不同的查询进行优化。

不同排序规则,可被看成物化视图,但它们是物理数据结构,不是辅助索引。它不包含聚集、连接、额外的查询,认为它们在现实的分布式数据库中是不切实际的。

2.2连接索引,没有被实现,代价比带来的优势要少,实现复杂,执行代价在重现全元组在分布式查询时很高。
明确存储行ID,会点用很多空间,我们高效的压缩实现有助于减少这种开销,但没有计划实现它
3.3预连接推算
没有预期使用的多和重要:在小表连接操作上已经够好(高度优化的hash和合并算法),用户一般不愿意减慢
批量数据加载数据去优化查询速度。在加载数据时比连接查询时能够进行的优化机会要少,因为数据库在加载流中没有什么先验。

3.4 编码和压缩
不同列有不同的编码,同样的列在他们的每个推测中也可有不同的编码
自动:根据类型和配置,当使用场景不同确时
替换:低基数列

3.5 分区
c-store节点内水平分区,在单个节点使用并行提升性能
获得节点性并行并不需要硬盘物理分隔,在运行时逻辑分区,然后并行处理。尽管能够自动并行化,也提供根据value保持在物理上隔离
分区原因:快速批量删除(其它系统分区也是如此),否则需要查询所有物理文件要删除的行,添加删除标记,比起直接删文件慢的多
增加了存储的需求,在元组没有执行合并操作前影响查询性能。如果分区在所有推算上都一致,批量删除才是快速的,所以它是表层次的,而不是推算层次的

分区原因:增加查询性能,它保存最小值和最大值在每个ROS中,在做计划时就能够修剪容器。分区使这种技术更高效,分区使列数据不混合

3.6 分割:集群分布
可以指定列做hash到段
c-store根据projection的排序字段的第一个列分割物理存储到段
完全的分布式存储系统,分配存储元组到不同计算结点
节点内水平分区和节点外水平分区(分割)
分割对每个推算在排序方式上可能不同,推算分割提供决定把元组映射到节点,可以做许多重要的优化。(
完全本地分式连接,高效的分布式聚合,计算高基数不同的集合特别高效
复制推算在每个node上分布,分割推算一个元组在单个推算节点上存储
保持元组物理隔离为本地段,以方便集群的在线扩展与收缩

3.7读写优化存储
写在内存中,读在磁盘中
读:完整的依据推算排序排序的元组,列存储为一系列文件,两个文件1真实列数据2列数据索引
(大约1/1000,包含MetaData,如,开始位置,最大,最小值,固定不变故没有采用B-Tree)
写:内存,行列格式无关紧要,无编码和压缩,为缓冲数据操作(增、删、改)保证操作有足够多的行数以减少写的代价,
会随时间在行列模式下切换(和性能无关,只是软件工程考虑)
但它会以推算的分段表达式进行分段
3.7.1数据修改删除象量
不直接修改,当U和D操作时,创建D象量,它是要删除行的位置的列表,可能会有多个
DVWOS-》DVROS 高效的压缩
修改=删除+插入

4、无组移动:提高数据存储和查询效率
异步把数据从写优化到读优化,当WOS饱和mover操作没有完成之前,加载的数据直接入ROS,直到WOS重新获得足够的能力。mover平衡工作,避免产生小的ROS
读优化文件合并,减少ROS文件数量
写填满-》自动开始移动操作(随后的数据直接写到读优化,直到写有足够的空间)-》移动操作不能过多也不能过少
小文件影响压缩、减慢查询,需要更多文件句柄、seek和更多的全并排序文件的操作。
合并操作:回收已标记为删除的元组
没有限制ROS Containers大小,但它不会创建超过一定大小的(当前2T),足够大(每文件开销分摊,管理不笨重)
ROS层在Node间是私有的,不会在集群内协调

5、修改和事务
每个元组都和提交时间关联(纪元)(隐式64bit的列或删除象量)
所有节点在事务提交都同意其包含的纪元,就相当于有了全局的一致性快照,读无需要加锁
有一个分析工作量的表锁定模式
不使用传统的两阶段提交
共享锁:限制并发修改表,用来实现序列化隔离
插入锁:插入数据时到表使用,和自己兼容,支持匹量插入和加载同时发生,以保持高插入加载速度。但仍然提供事务语义
共享插入锁:读写
独占锁:删改
元组移动锁:和所有锁兼容除了X锁,在元组移动同时操作删除象量时
使用锁:
拥有锁:

分布式和组成员协议来协调集群内结点之间操作,使用广播和点对点来保证所有控制消息成功送达所有node
提交在集群中成功如果它在选定数据的结点上成功,ROS与WOS创建的事务完成后其它事务才能看到

5.1纪元管理
纪元模型:纪元包含给定时间窗口所有提交了的事务
Last Good Epoch:所有数据都成功从WOS移动到ROS
Ancient History Mark:

5.2宽容失败
Vertica的数据复制通过使用Projection分段机制,以提供容错
每个Projection,必须至少有一个伙伴projection含有相同的列和分割以确保任何行被存储在同一样节点的Projection,当节点故障,伙伴projection会做为故障节点的源。
不需要传统的事务日志,数据+纪元自己就做为过去系统活动日志。vertica使用这些历史数据,去重放节点丢失的DML。节点会从正常的伙伴projection数据段恢复数据,

恢复,更新,重新平衡和备份都是在线操作;在执行这些操作同时可进行数据的加载和查询。影响的只是计算和带宽资源。

5.3
以元数据目录在节点间管理状态,它记录着表、用户、节点、纪元等的信息。
没有保存在数据库表中,因为它的表设计无法恰当的通过catalog访问和修改。它采用自定义的内存结构中,然后通过它自己的事务机制保存到磁盘中。
k-safety:当有小于或等于K个节点故障,集群仍然可用。
数据库projection必须确保有K+1个每个段的拷贝在不同的节点上。当有一半节点故障,集群会保护性关闭。集群必须保证有n/2+1个节点确保脑裂后的两个集群继续提供服务。

6 查询的执行
私有扩展标准的SQL声明的查询语言。
Vertica的公司扩展设计使可轻松地查询在SQL时过于繁琐或不可能的时间序列和日志型数据。

6.1查询操作符和计划格式
执行引擎为完全天量化,并且在同时查询一块行数据而不是同时查询单一行
标准操作树,每个操作执行一个特定的算法。一个操作者的输出做为下面操作者的输入。
执行引擎是多线程和流水线的
在一个时间请求一块行数据而不是请求一条数据。
使用上拉处理模型,直到一个操作从磁盘或网络读到数据。
扫描、分组(有多个算法依据性能最大化、内存需求、操作是否必须产生单独的组决定使用那个,并且实现了管道聚合方式可选择是否保持数据编码)、连接(实现了hash join和merge join算法,能够在必要时外部化)、表达式执行、排序、分析、发送/接收

特别处理和复杂的实现,确保可直接操作未解码的数据,这对于扫描、joins、低级聚集操作很重要。

SIP:Sideways Infomation Passing,侧面消息传递,采用在查询计划中尽可能早的过滤数据来优化join性能。(可在优化查询计算时就构建SIP filter,然后在执行时使用。在执行时,扫描操作会扫描join的hash table,SIP会用来判断outer key值在hash 表中是否存在。)

运行期间分析数据调整算法(内存不够hashtable->sort-merge join;生成预处理操作,并发执行,最后根据它们的结果生成最终数据)

晚物化、压缩的成本和估算、流聚合、消除排序、合并连接、不可见索引(每列按选择性排序,不需要索引来减少IO和更快查找值),数据die dai(L2缓存,更好的利用二级缓存和多核并发的特性)

使用pipeline执行引擎带来挑战是共享公共资源,可能造成不必要的yi chu到磁盘。vartica会把计划分成多个不会在同一时间执行的区,下游操作会回收上游操作的资源。

不同表的projection的数据被复制到所有节点上或者在join key上分割相同的范围,使得计划可以在每个节点的内部执行,然后结果发送到客户端连接的结点。

6.2 优化

选择和连接projections,保证scan和join更快(保证之后join的数据被减少)

收集性能数据(压缩I/O,CPU,网络使用),

Posted in 数据库 | Leave a comment

ToKuDB简要

介绍
TokuDB存储引擎是Tokutek2009年发布的一个数据库存储引擎,于2013年4月开源。支持MySQL/MariaDB。它和InnoDB一样支持事务、MVCC。

特色:
Franctal Tree而不是B-Tree
内部结点不仅有指向父子的指针还有Buffer区,数据写入先写buffer区,FIFO结构,写入只需要顺序添加到Buffer区就可返回,后续满时一次性刷新到下面的子树中,插入数据基本上是一个顺序添加的过程。可轻松应对随机IO,减少空间碎片。
出色的压缩性能
块大小默认是4MB
在线DDL

数据结构:
一、Buffered Tree:类B-Tree,写时直接写到Root结点,如果Root结点满了,就把数据刷新到它子结点上,如果子结点满了就继续刷新到子子结点,一直这样下去。因此,只有当结点满时才有Disk Seek产生。Node大小可设置很大,比如4MB,为提高读,需要对Node做更细划分,分成小块,随机读IO复杂度也为O(logN)。
写:
写时不产生disk seek,因为总是先写Root,由于经常被操作,可认为树顶部结点一直在Page Cache中。
节点数据紧凑,大Node压缩有优势
天然适合做事务,没有undo log,叶子结点上做mvcc

二、Fractal-Tree(Buffer-Tree的变种)
buffered(4,16)-tree,OMT结构维护结点数据,大小4MB,nonleaf节点OMT结构,leaf节点多个OMT(4MB/64KB)

OMT:Order Maintenance Tree
元素用数组表示,具有父子关系的元素尽量相邻存储,cpu cache line(如果一个节点的周边节点能在文件中紧邻的被存储,当读取其中一个的时候,其他节点被prefetching出来,io数则可以减少。这就是vEB layout)

结点刷新:Node完成写时检查是否满足flush条件,满足加到flush队列,后台线程并行处理从队列中读取的任务。

CheckPoint:60秒一次,sharp checkpoint无Fuzz Checkpoint,会对所有索引加只读锁,其它线程写node时,会clone一个Node。做完后检查LSN,以清理无用的log。基本上这个操作不影响前台读写操作,但是因为会进行数据压缩和clone node、写磁盘的操作,会造成一定的性能波动。

Cache:LRU,写cache时添加node到cache链表,然后检查cache状态,设置了四个水平位(低水平位,低警示点,高警示点,高水平位),高于高水平位,客户端线程进入等待状态,超过低警示点,开始收集逐出数据。

三、读:
KEY读:每次读数据都要从ROOT到LEAF,做数据合并,才能得到完整的ROW数据。
范围读:对树做深度优先遍历,在LEAF结点返回,痛苦。

四、Schema Changes
列修改:Broadcast类型的Message,从Root广播到每一节点,最后到达LEAF结点。(Mysql对列修改会先关闭表,再打开表,关闭时Tokudb会把脏Node写盘,有些性能消耗),腾讯的游戏运维部门在InnoDB上实现了类似的功能。

索引:两种索引,cst_(clustering index)和cvr_(covering index),每个都是一个单独的F-tree文件
offline方式:启动多个线程,遍历记录生成索引,速度快,但创建过程中写操作不可用。
hot方式:速度慢,创建过程读写不受影响

log:log manager来管理log文件,无重做日志组的概念,当日志写满后重新生成一个文件继续写,checkpoint后检查数据都被刷新到磁盘后会删除,达到InnoDB类似的效果;分in buffer和out buffer(都是16MB),在两块内存上来回倒,多线程下锁控制方便。

优点
高压缩比,写性能高,DDL速度超快
缺点
cpu usr态消耗,响应时间变长
场景
插入效率高、压缩效率好、可在线DDL,适合写性能要求高,数据量过亿,记录不是太大的场合。

大压缩比所以CPU的USR态有消耗
相同QPS时读IOPS差别不大,写IOPS InnoDB平均多消耗些
TokuDB数据经过压缩,但会有解压消耗,所以结果不好确定,测试上看响应时间高于InnoDB

IOPS (Input/Output Operations Per Second),即每秒进行读写(I/O)操作的次数。
QPS:Queries Per Second意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

Posted in MySQL, 数据库 | Leave a comment

如何取得jvm实例的cpu占用

本文会贴很多代码,代码遵循Google的java代码格式。

获取数据篇

1、jmx连接的创建是一个比较重的操作,我们使用apache的common pool2创建连接工厂。

public class JmxConnectionFactory implements KeyedPooledObjectFactory<JmxServer, JMXConnector> {

  @Override
  public PooledObject<JMXConnector> makeObject(JmxServer server) throws Exception {
    JMXServiceURL
        serviceURL =
        new JMXServiceURL(String.format(
            "service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", server.getHost(), server.getPort()));
    Map<String, Object> environment = Maps.newHashMap();
    String username = server.getUsername();
    String password = server.getPassword();
    if ((username != null) && (password != null)) {
      String[] credentials = new String[2];
      credentials[0] = username;
      credentials[1] = password;
      environment.put(JMXConnector.CREDENTIALS, credentials);
    }
    environment.put("sun.rmi.transport.proxy.connectTimeout", 1000);
    environment.put("sun.rmi.transport.tcp.responseTimeout", 3000);
    JMXConnector connect = JMXConnectorFactory.connect(serviceURL, environment);
    return new DefaultPooledObject<JMXConnector>(connect);


  }

  @Override
  public void destroyObject(JmxServer key, PooledObject<JMXConnector> object) throws Exception {
    object.getObject().close();
  }

  @Override
  public boolean validateObject(JmxServer key, PooledObject<JMXConnector> object) {
    JMXConnector connector = object.getObject();
    try {
      connector.getConnectionId();
      return true;
    } catch (IOException exception) {
      // ignore
    }
    return false;
  }

  @Override
  public void activateObject(JmxServer key, PooledObject<JMXConnector> p) throws Exception {
  }

  @Override
  public void passivateObject(JmxServer key, PooledObject<JMXConnector> p) throws Exception {
  }
}

2、从连接池中获取JMX连接

  private static GenericKeyedObjectPool<JmxServer, JMXConnector> POOL;
  private static AtomicInteger actives = new AtomicInteger(0);
  //....
try {
      JMXConnector connector = POOL.borrowObject(server);
      try {
        MBeanServerConnection mbsc = connector.getMBeanServerConnection();
        // 在这个地方使用连接获取JVM的监控数据
        // ......
      } finally {
        POOL.returnObject(server, connector);
      }

3、计算cpu占用的逻辑是:
获取:ProcessCpuTime,Uptime,AvailableProcessors,然后结合上一次获取到的数据得出,算式为:

Math.min(99F, (ProcessCpuTime-PreProcessCpuTime) / ((Uptime-PreUptime) * 10000F * AvailableProcessors));

方式一:通过获取相应的Bean,然后通过Bean去获取数据

private long prevUpTime, prevProcessCpuTime;
// ......
      RuntimeMXBean runtimeMBean =
          newPlatformMXBeanProxy(mbsc, RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
      OperatingSystemMXBean
          operatingSystemMBean =
          newPlatformMXBeanProxy(mbsc, OPERATING_SYSTEM_MXBEAN_NAME,
                                 com.sun.management.OperatingSystemMXBean.class);
      int nCPUs = operatingSystemMBean.getAvailableProcessors();
      if (runtimeMBean != null && operatingSystemMBean != null) {
        long uptime = runtimeMBean.getUptime();
        long processCpuTime = operatingSystemMBean.getProcessCpuTime();
        if (prevUpTime != 0 && prevProcessCpuTime != 0) {
          long elapsedCpu = processCpuTime - prevProcessCpuTime;
          long elaspedTime = uptime - prevUpTime;
          float cpuUsage = Math.min(99F, elapsedCpu / (elaspedTime * 10000F * nCPUs));
          prevUpTime = uptime;
          prevProcessCpuTime = processCpuTime;
          //
          JsonObject value = new JsonObject();
          String key = "CpuUsage";
          LOGGER.debug("received value '{}%' for item '{}'", cpuUsage, key);
          value.addProperty(MonitorConst.JSON_TAG_VALUE, cpuUsage);
          value.addProperty(MonitorConst.JSON_TAG_NAME, key);
          return value;
        } else {
          prevUpTime = uptime;
          prevProcessCpuTime = processCpuTime;
        }
      }
// ......

方式二、通过key来直接获取,代码通用些,比较长,代码参考zabbix gateway实现

// 通用获取方法
protected String getStringValue(MBeanServerConnection mbsc, String key) throws Exception {
    MonitorItem item = new MonitorItem(key);

    if (item.getKeyId().equals("jmx")) {
      if (2 != item.getArgumentCount()) {
        throw new MonitorException(
            "required key format: jmx[<object name>,<attribute name>]");
      }

      ObjectName objectName = new ObjectName(item.getArgument(1));
      String attributeName = item.getArgument(2);
      String realAttributeName;
      String fieldNames = "";
      int sep;

      //
      // Attribute name and composite data field names are separated by dots. On the other hand the
      // name may contain a dot too. In this case user needs to escape it with a backslash. Also the
      // backslash symbols in the name must be escaped. So a real separator is unescaped dot and
      // separatorIndex() is used to locate it.
      //

      sep = HelperFunctionChest.separatorIndex(attributeName);

      if (-1 != sep) {
        LOGGER.trace("'{}' contains composite data", attributeName);

        realAttributeName = attributeName.substring(0, sep);
        fieldNames = attributeName.substring(sep + 1);
      } else {
        realAttributeName = attributeName;
      }

      // unescape possible dots or backslashes that were escaped by user
      realAttributeName = HelperFunctionChest.unescapeUserInput(realAttributeName);

      LOGGER.trace("attributeName:'{}'", realAttributeName);
      LOGGER.trace("fieldNames:'{}'", fieldNames);

      return getPrimitiveAttributeValue(mbsc.getAttribute(objectName, realAttributeName),
                                        fieldNames);
    } else if (item.getKeyId().equals("jmx.discovery")) {
      if (0 != item.getArgumentCount()) {
        throw new MonitorException("required key format: jmx.discovery");
      }

      JsonArray counters = new JsonArray();

      for (ObjectName name : mbsc.queryNames(null, null)) {
        LOGGER.trace("discovered object '{}'", name);

        for (MBeanAttributeInfo attrInfo : mbsc.getMBeanInfo(name).getAttributes()) {
          LOGGER.trace("discovered attribute '{}'", attrInfo.getName());

          if (!attrInfo.isReadable()) {
            LOGGER.trace("attribute not readable, skipping");
            continue;
          }

          try {
            LOGGER.trace("looking for attributes of primitive types");
            String
                descr =
                (attrInfo.getName().equals(attrInfo.getDescription()) ? null
                                                                      : attrInfo
                     .getDescription());
            findPrimitiveAttributes(counters, name, descr, attrInfo.getName(),
                                    mbsc.getAttribute(name, attrInfo.getName()));
          } catch (Exception e) {
            Object[] logInfo = {name, attrInfo.getName(), e};
            LOGGER.trace("processing '{},{}' failed", logInfo);
          }
        }
      }

      JsonObject mapping = new JsonObject();
      mapping.add(MonitorConst.JSON_TAG_DATA, counters);
      return mapping.toString();
    } else {
      throw new MonitorException("key ID '%s' is not supported", item.getKeyId());
    }
  }

  private String getPrimitiveAttributeValue(Object dataObject, String fieldNames) throws
                                                                                  MonitorException {
    LOGGER
        .trace("drilling down with data object '{}' and field names '{}'", dataObject,
               fieldNames);

    if (null == dataObject) {
      throw new MonitorException("data object is null");
    }

    if (fieldNames.equals("")) {
      if (isPrimitiveAttributeType(dataObject.getClass())) {
        return dataObject.toString();
      } else {
        throw new MonitorException(
            "data object type is not primitive: %s" + dataObject.getClass());
      }
    }

    if (dataObject instanceof CompositeData) {
      LOGGER.trace("'{}' contains composite data", dataObject);

      CompositeData comp = (CompositeData) dataObject;

      String dataObjectName;
      String newFieldNames = "";

      int sep = HelperFunctionChest.separatorIndex(fieldNames);

      if (-1 != sep) {
        dataObjectName = fieldNames.substring(0, sep);
        newFieldNames = fieldNames.substring(sep + 1);
      } else {
        dataObjectName = fieldNames;
      }

      // unescape possible dots or backslashes that were escaped by user
      dataObjectName = HelperFunctionChest.unescapeUserInput(dataObjectName);

      return getPrimitiveAttributeValue(comp.get(dataObjectName), newFieldNames);
    } else {
      throw new MonitorException("unsupported data object type along the path: %s",
                                 dataObject.getClass());
    }
  }

  private void findPrimitiveAttributes(JsonArray counters, ObjectName name, String descr,
                                       String attrPath, Object attribute) {
    LOGGER.trace("drilling down with attribute path '{}'", attrPath);

    if (isPrimitiveAttributeType(attribute.getClass())) {
      LOGGER.trace("found attribute of a primitive type: {}", attribute.getClass());

      JsonObject counter = new JsonObject();

      counter.addProperty("{#JMXDESC}", null == descr ? name + "," + attrPath : descr);
      counter.addProperty("{#JMXOBJ}", name.toString());
      counter.addProperty("{#JMXATTR}", attrPath);
      counter.addProperty("{#JMXTYPE}", attribute.getClass().getName());
      counter.addProperty("{#JMXVALUE}", attribute.toString());

      counters.add(counter);
    } else if (attribute instanceof CompositeData) {
      LOGGER.trace("found attribute of a composite type: {}", attribute.getClass());

      CompositeData comp = (CompositeData) attribute;

      for (String key : comp.getCompositeType().keySet()) {
        findPrimitiveAttributes(counters, name, descr, attrPath + "." + key, comp.get(key));
      }
    } else if (attribute instanceof TabularDataSupport || attribute.getClass().isArray()) {
      LOGGER.trace("found attribute of a known, unsupported type: {}", attribute.getClass());
    } else {
      LOGGER
          .trace("found attribute of an unknown, unsupported type: {}", attribute.getClass());
    }
  }

  private boolean isPrimitiveAttributeType(Class<?> clazz) {
    Class<?>[]
        clazzez =
        {Boolean.class, Character.class, Byte.class, Short.class, Integer.class, Long.class,
         Float.class, Double.class, String.class, java.math.BigDecimal.class,
         java.math.BigInteger.class,
         java.util.Date.class, ObjectName.class};

    return HelperFunctionChest.arrayContains(clazzez, clazz);
  }
// 使用示例
获取:ProcessCpuTime,Uptime,AvailableProcessors,然后结合上一次获取到的数据得出,算式为:
String processCpuTime=getStringValue(mbsc, "jmx[\"java.lang:type=OperatingSystem\",ProcessCpuTime]")
String uptime=getStringValue(mbsc, "jmx[\"java.lang:type=Runtime\",Uptime]", #1)-last("jmx[\"java.lang:type=Runtime\",Uptime]")
String availableProcessors=getStringValue(mbsc, "jmx[\"java.lang:type=OperatingSystem\",AvailableProcessors]")

方式三、zabbix
1、clone一个Template JMX Generic,修改添加相应的item的配置,添加的Template JMX Consumer

      <template>
            <template>Template JMX Consumer</template>
            <name>Template JMX Consumer</name>
            <groups>
                <group>
                    <name>Templates</name>
                </group>
            </groups>
            <applications/>
            <items>
                <item>
                    <name>AvailableProcessors</name>
                    <type>16</type>
                    <snmp_community/>
                    <multiplier>0</multiplier>
                    <snmp_oid/>
                    <key>jmx["java.lang:type=OperatingSystem",AvailableProcessors]</key>
                    <delay>60</delay>
                    <history>7</history>
                    <trends>365</trends>
                    <status>0</status>
                    <value_type>3</value_type>
                    <allowed_hosts/>
                    <units/>
                    <delta>0</delta>
                    <snmpv3_contextname/>
                    <snmpv3_securityname/>
                    <snmpv3_securitylevel>0</snmpv3_securitylevel>
                    <snmpv3_authprotocol>0</snmpv3_authprotocol>
                    <snmpv3_authpassphrase/>
                    <snmpv3_privprotocol>0</snmpv3_privprotocol>
                    <snmpv3_privpassphrase/>
                    <formula>1</formula>
                    <delay_flex/>
                    <params/>
                    <ipmi_sensor/>
                    <data_type>0</data_type>
                    <authtype>0</authtype>
                    <username/>
                    <password/>
                    <publickey/>
                    <privatekey/>
                    <port/>
                    <description/>
                    <inventory_link>0</inventory_link>
                    <applications>
                        <application>
                            <name>Operating System</name>
                        </application>
                    </applications>
                    <valuemap/>
                </item>
                <item>
                    <name>Cpu Usage</name>
                    <type>15</type>
                    <snmp_community/>
                    <multiplier>0</multiplier>
                    <snmp_oid/>
                    <key>CpuUsage</key>
                    <delay>30</delay>
                    <history>7</history>
                    <trends>365</trends>
                    <status>0</status>
                    <value_type>0</value_type>
                    <allowed_hosts/>
                    <units>%</units>
                    <delta>0</delta>
                    <snmpv3_contextname/>
                    <snmpv3_securityname/>
                    <snmpv3_securitylevel>0</snmpv3_securitylevel>
                    <snmpv3_authprotocol>0</snmpv3_authprotocol>
                    <snmpv3_authpassphrase/>
                    <snmpv3_privprotocol>0</snmpv3_privprotocol>
                    <snmpv3_privpassphrase/>
                    <formula>1</formula>
                    <delay_flex/>
                    <params>(last("jmx[\"java.lang:type=OperatingSystem\",ProcessCpuTime]", #1)-last("jmx[\"java.lang:type=OperatingSystem\",ProcessCpuTime]", #2))/((last("jmx[\"java.lang:type=Runtime\",Uptime]", #1)-last("jmx[\"java.lang:type=Runtime\",Uptime]", #2))*10000*last("jmx[\"java.lang:type=OperatingSystem\",AvailableProcessors]", 0))</params>
                    <ipmi_sensor/>
                    <data_type>0</data_type>
                    <authtype>0</authtype>
                    <username/>
                    <password/>
                    <publickey/>
                    <privatekey/>
                    <port/>
                    <description/>
                    <inventory_link>0</inventory_link>
                    <applications>
                        <application>
                            <name>Runtime</name>
                        </application>
                    </applications>
                    <valuemap/>
                </item>
                <item>
                    <name>ProcessCpuTime</name>
                    <type>16</type>
                    <snmp_community/>
                    <multiplier>0</multiplier>
                    <snmp_oid/>
                    <key>jmx["java.lang:type=OperatingSystem",ProcessCpuTime]</key>
                    <delay>60</delay>
                    <history>7</history>
                    <trends>365</trends>
                    <status>0</status>
                    <value_type>3</value_type>
                    <allowed_hosts/>
                    <units/>
                    <delta>0</delta>
                    <snmpv3_contextname/>
                    <snmpv3_securityname/>
                    <snmpv3_securitylevel>0</snmpv3_securitylevel>
                    <snmpv3_authprotocol>0</snmpv3_authprotocol>
                    <snmpv3_authpassphrase/>
                    <snmpv3_privprotocol>0</snmpv3_privprotocol>
                    <snmpv3_privpassphrase/>
                    <formula>1</formula>
                    <delay_flex/>
                    <params/>
                    <ipmi_sensor/>
                    <data_type>0</data_type>
                    <authtype>0</authtype>
                    <username/>
                    <password/>
                    <publickey/>
                    <privatekey/>
                    <port/>
                    <description/>
                    <inventory_link>0</inventory_link>
                    <applications>
                        <application>
                            <name>Operating System</name>
                        </application>
                    </applications>
                    <valuemap/>
                </item>
            </items>
            <discovery_rules/>
            <macros/>
            <templates>
                <template>
                    <name>Template JMX Generic</name>
                </template>
            </templates>
            <screens/>
        </template>
// 修改原来的模板
<item>
                    <name>jvm Uptime</name>
                    <type>15</type>
                    <snmp_community/>
                    <multiplier>1</multiplier>
                    <snmp_oid/>
                    <key>jmxUptime</key>
                    <delay>60</delay>
                    <history>7</history>
                    <trends>365</trends>
                    <status>0</status>
                    <value_type>3</value_type>
                    <allowed_hosts/>
                    <units>uptime</units>
                    <delta>0</delta>
                    <snmpv3_contextname/>
                    <snmpv3_securityname/>
                    <snmpv3_securitylevel>0</snmpv3_securitylevel>
                    <snmpv3_authprotocol>0</snmpv3_authprotocol>
                    <snmpv3_authpassphrase/>
                    <snmpv3_privprotocol>0</snmpv3_privprotocol>
                    <snmpv3_privpassphrase/>
                    <formula>0.001</formula>
                    <delay_flex/>
                    <params>jmx["java.lang:type=Runtime",Uptime]</params>
                    <ipmi_sensor/>
                    <data_type>0</data_type>
                    <authtype>0</authtype>
                    <username/>
                    <password/>
                    <publickey/>
                    <privatekey/>
                    <port/>
                    <description/>
                    <inventory_link>0</inventory_link>
                    <applications>
                        <application>
                            <name>Runtime</name>
                        </application>
                    </applications>
                    <valuemap/>
                </item>
                <item>
                    <name>jvm Uptime Microsecond</name>
                    <type>16</type>
                    <snmp_community/>
                    <multiplier>0</multiplier>
                    <snmp_oid/>
                    <key>jmx["java.lang:type=Runtime",Uptime]</key>
                    <delay>60</delay>
                    <history>7</history>
                    <trends>365</trends>
                    <status>0</status>
                    <value_type>3</value_type>
                    <allowed_hosts/>
                    <units>uptime</units>
                    <delta>0</delta>
                    <snmpv3_contextname/>
                    <snmpv3_securityname/>
                    <snmpv3_securitylevel>0</snmpv3_securitylevel>
                    <snmpv3_authprotocol>0</snmpv3_authprotocol>
                    <snmpv3_authpassphrase/>
                    <snmpv3_privprotocol>0</snmpv3_privprotocol>
                    <snmpv3_privpassphrase/>
                    <formula>1</formula>
                    <delay_flex/>
                    <params/>
                    <ipmi_sensor/>
                    <data_type>0</data_type>
                    <authtype>0</authtype>
                    <username/>
                    <password/>
                    <publickey/>
                    <privatekey/>
                    <port/>
                    <description/>
                    <inventory_link>0</inventory_link>
                    <applications>
                        <application>
                            <name>Runtime</name>
                        </application>
                    </applications>
                    <valuemap/>
                </item>

Posted in Java语言, kafka | Leave a comment

数字证书原理

转载:     数字证书原理 – 无恙

文中首先解释了加密解密的一些基础知识和概念,然后通过一个加密通信过程的例子说明了加密算法的作用,以及数字证书的出现所起的作用。接着对数字证书做一个详细的解释,并讨论一下windows中数字证书的管理,最后演示使用makecert生成数字证书。如果发现文中有错误的地方,或者有什么地方说得不够清楚,欢迎指出!

1、基础知识

      这部分内容主要解释一些概念和术语,最好是先理解这部分内容。

1.1、公钥密码体制(public-key cryptography)

公钥密码体制分为三个部分,公钥私钥、加密解密算法,它的加密解密过程如下:

  • 加密:通过加密算法公钥对内容(或者说明文)进行加密,得到密文。加密过程需要用到公钥
  • 解密:通过解密算法私钥密文进行解密,得到明文。解密过程需要用到解密算法私钥。注意,公钥加密的内容,只能由私钥进行解密,也就是说,由公钥加密的内容,如果不知道私钥,是无法解密的。

公钥密码体制公钥和算法都是公开的(这是为什么叫公钥密码体制的原因),私钥是保密的。大家都以使用公钥进行加密,但是只有私钥的持有者才能解密。在实际的使用中,有需要的人会生成一对公钥私钥,把公钥发布出去给别人使用,自己保留私钥

1.2、对称加密算法(symmetric key algorithms)

对称加密算法中,加密使用的密钥和解密使用的密钥是相同的。也就是说,加密和解密都是使用的同一个密钥。因此对称加密算法要保证安全性的话,密钥要做好保密,只能让使用的人知道,不能对外公开。这个和上面的公钥密码体制有所不同,公钥密码体制中加密是用公钥,解密使用私钥,而对称加密算法中,加密和解密都是使用同一个密钥,不区分公钥私钥

        // 密钥,一般就是一个字符串或数字,在加密或者解密时传递给加密/解密算法。前面在公钥密码体制中说到的公钥私钥就是密钥公钥是加密使用的密钥私钥是解密使用的密钥

 
1.3、非对称加密算法(asymmetric key algorithms)

非对称加密算法中,加密使用的密钥和解密使用的密钥是不相同的。前面所说的公钥密码体制就是一种非对称加密算法,他的公钥和是私钥是不能相同的,也就是说加密使用的密钥和解密使用的密钥不同,因此它是一个非对称加密算法

1.4、RSA简介

RSA是一种公钥密码体制,现在使用得很广泛。如果对RSA本身有兴趣的,后面看我有没有时间写个RSA的具体介绍。

RSA密码体制是一种公钥密码体制,公钥公开,私钥保密,它的加密解密算法是公开的。 由公钥加密的内容可以并且只能由私钥进行解密,并且由私钥加密的内容可以并且只能由公钥进行解密。也就是说,RSA的这一对公钥、私钥都可以用来加密和解密,并且一方加密的内容可以由并且只能由对方进行解密

1.5、签名和加密

我们说加密,是指对某个内容加密加密后的内容还可以通过解密进行还原。 比如我们把一封邮件进行加密,加密后的内容在网络上进行传输,接收者在收到后,通过解密可以还原邮件的真实内容。

这里主要解释一下签名签名就是在信息的后面再加上一段内容,可以证明信息没有被修改过,怎么样可以达到这个效果呢?一般是对信息做一个hash计算得到一个hash值,注意,这个过程是不可逆的,也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时,把这个hash值加密后做为一个签名信息一起发出去。 接收方在收到信息后,会重新计算信息的hash值,并和信息所附带的hash值(解密后)进行对比,如果一致,就说明信息的内容没有被修改过,因为这里hash计算可以保证不同的内容一定会得到不同的hash值,所以只要内容一被修改,根据信息内容计算的hash值就会变化。当然,不怀好意的人也可以修改信息内容的同时也修改hash值,从而让它们可以相匹配,为了防止这种情况,hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。至于如何让别人可以解密这个签名,这个过程涉及到数字证书等概念,我们后面在说到数字证书时再详细说明,这里您先只需先理解签名的这个概念。

2、一个加密通信过程的演化

      我们来看一个例子,现在假设“服务器”和“客户”要在网络上通信,并且他们打算使用RSA(参看前面的RSA简介)来对通信进行加密以保证谈话内容的安全。由于是使用RSA这种公钥密码体制,“服务器”需要对外发布公钥(算法不需要公布,RSA的算法大家都知道),自己留着私钥。“客户”通过某些途径拿到了“服务器”发布的公钥,客户并不知道私钥。“客户”具体是通过什么途径获取公钥的,我们后面再来说明,下面看一下双方如何进行保密的通信:

2.1 第一回合:

“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:????
因为消息是在网络上传输的,有人可以冒充自己是“服务器”来向客户发送信息。例如上面的消息可以被黑客截获如下:
“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“黑客”:你好        // 黑客在“客户”和“服务器”之间的某个路由器上截获“客户”发给服务器的信息,然后自己冒充“服务器”
“黑客”->“客户”:你好,我是服务器

因此“客户”在接到消息后,并不能肯定这个消息就是由“服务器”发出的,某些“黑客”也可以冒充“服务器”发出这个消息。如何确定信息是由“服务器”发过来的呢?有一个解决方法,因为只有服务器有私钥,所以如果只要能够确认对方有私钥,那么对方就是“服务器”。因此通信过程可以改进为如下:

2.2 第二回合:

“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

      // 意这里约定一下,{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密,后面的示例中都用这种表示方式,例如上面的 {你好,我是服务器}[私钥|RSA]  就表示用私钥“你好,我是服务器”进行加密后的结果。

为了向“客户”证明自己是“服务器”, “服务器”把一个字符串用自己的私钥加密,把明文和加密后的密文一起发给“客户”。对于这里的例子来说,就是把字符串 “你好,我是服务器”和这个字符串用私钥加密后的内容 {你好,我是服务器}[私钥|RSA] 发给客户。
“客户”收到信息后,她用自己持有的公钥解密密文,和明文进行对比,如果一致,说明信息的确是由服务器发过来的。也就是说“客户”把 {你好,我是服务器}[私钥|RSA] 这个内容用公钥进行解密,然后和“你好,我是服务器”对比。因为由“服务器”用私钥加密后的内容,由并且只能由公钥进行解密,私钥只有“服务器”持有,所以如果解密出来的内容是能够对得上的,那说明信息一定是从“服务器”发过来的。

假设“黑客”想冒充“服务器”:

“黑客”->“客户”:你好,我是服务器
“客户”->“黑客”:向我证明你就是服务器
“黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[???|RSA]    //这里黑客无法冒充,因为他不知道私钥,无法用私钥加密某个字符串后发送给客户去验证。
“客户”->“黑客”:????

由于“黑客”没有“服务器”的私钥,因此它发送过去的内容,“客户”是无法通过服务器的公钥解密的,因此可以认定对方是个冒牌货!

到这里为止,“客户”就可以确认“服务器”的身份了,可以放心和“服务器”进行通信,但是这里有一个问题,通信的内容在网络上还是无法保密。为什么无法保密呢?通信过程不是可以用公钥私钥加密吗?其实用RSA的私钥公钥是不行的,我们来具体分析下过程,看下面的演示:

2.3 第三回合:

“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[公钥|RSA]
“服务器”->“客户”:{你的余额是100元}[私钥|RSA]

注意上面的的信息 {你的余额是100元}[私钥],这个是“服务器”用私钥加密后的内容,但是我们之前说了,公钥是发布出去的,因此所有的人都知道公钥,所以除了“客户”,其它的人也可以用公钥{你的余额是100元}[私钥]进行解密。所以如果“服务器”用私钥加密发给“客户”,这个信息是无法保密的,因为只要有公钥就可以解密这内容。然而“服务器”也不能用公钥对发送的内容进行加密,因为“客户”没有私钥,发送个“客户”也解密不了。

这样问题就又来了,那又如何解决呢?在实际的应用过程,一般是通过引入对称加密来解决这个问题,看下面的演示:

2.4 第四回合:

“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]
“客户”->“服务器”:{我们后面的通信过程,用对称加密来进行,这里是对称加密算法密钥}[公钥|RSA]    //蓝色字体的部分是对称加密的算法和密钥的具体内容,客户把它们发送给服务器。

“服务器”->“客户”:{OK,收到!}[密钥|对称加密算法]
“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]
“服务器”->“客户”:{你的余额是100元}[密钥|对称加密算法]

在上面的通信过程中,“客户”在确认了“服务器”的身份后,“客户”自己选择一个对称加密算法和一个密钥,把这个对称加密算法密钥一起用公钥加密后发送给“服务器”。注意,由于对称加密算法密钥是用公钥加密的,就算这个加密后的内容被“黑客”截获了,由于没有私钥,“黑客”也无从知道对称加密算法密钥的内容。

由于是用公钥加密的,只有私钥能够解密,这样就可以保证只有服务器可以知道对称加密算法密钥,而其它人不可能知道(这个对称加密算法密钥是“客户”自己选择的,所以“客户”自己当然知道如何解密加密)。这样“服务器”和“客户”就可以用对称加密算法密钥来加密通信的内容了。

总结一下,RSA加密算法在这个通信过程中所起到的作用主要有两个:

  • 因为私钥只有“服务器”拥有,因此“客户”可以通过判断对方是否有私钥来判断对方是否是“服务器”。
  • 客户端通过RSA的掩护,安全的和服务器商量好一个对称加密算法密钥来保证后面通信过程内容的安全。

如果这里您理解了为什么不用RSA去加密通信过程,而是要再确定一个对称加密算法来保证通信过程的安全,那么就说明前面的内容您已经理解了。(如果不清楚,再看下2.3和2.4,如果还是不清楚,那应该是我们说清楚,您可以留言提问。)

到这里,“客户”就可以确认“服务器”的身份,并且双方的通信内容可以进行加密,其他人就算截获了通信内容,也无法解密。的确,好像通信的过程是比较安全了。

但是这里还留有一个问题,在最开始我们就说过,“服务器”要对外发布公钥,那“服务器”如何把公钥发送给“客户”呢?我们第一反应可能会想到以下的两个方法:

a)把公钥放到互联网的某个地方的一个下载地址,事先给“客户”去下载。

b)每次和“客户”开始通信时,“服务器”把公钥发给“客户”。

但是这个两个方法都有一定的问题,

对于a)方法,“客户”无法确定这个下载地址是不是“服务器”发布的,你凭什么就相信这个地址下载的东西就是“服务器”发布的而不是别人伪造的呢,万一下载到一个假的怎么办?另外要所有的“客户”都在通信前事先去下载公钥也很不现实。

对于b)方法,也有问题,因为任何人都可以自己生成一对公钥私钥,他只要向“客户”发送他自己的私钥就可以冒充“服务器”了。示意如下:

“客户”->“黑客”:你好           //黑客截获“客户”发给“服务器”的消息

黑客”->“客户”:你好,我是服务器,这个是我的公钥    //黑客自己生成一对公钥私钥,把公钥发给“客户”,自己保留私钥

“客户”->“黑客”:向我证明你就是服务器

黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[黑客自己的私钥|RSA]      //客户收到“黑客”用私钥加密的信息后,是可以用“黑客”发给自己的公钥解密的,从而会误认为“黑客”是“服务器”

因此“黑客”只需要自己生成一对公钥私钥,然后把公钥发送给“客户”,自己保留私钥,这样由于“客户”可以用黑客的公钥解密黑客的私钥加密的内容,“客户”就会相信“黑客”是“服务器”,从而导致了安全问题。这里问题的根源就在于,大家都可以生成公钥私钥对,无法确认公钥对到底是谁的如果能够确定公钥到底是谁的,就不会有这个问题了。例如,如果收到“黑客”冒充“服务器”发过来的公钥,经过某种检查,如果能够发现这个公钥不是“服务器”的就好了。

为了解决这个问题,数字证书出现了,它可以解决我们上面的问题。先大概看下什么是数字证书,一个证书包含下面的具体内容:

  • 证书的发布机构
  • 证书的有效期
  • 公钥
  • 证书所有者(Subject)
  • 签名所使用的算法
  • 指纹以及指纹算法

证书的内容的详细解释会在后面详细解释,这里先只需要搞清楚一点,数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的,或者证书可以用来确认对方的身份。也就是说,我们拿到一个数字证书,我们可以判断出这个数字证书到底是谁的。至于是如何判断的,后面会在详细讨论数字证书时详细解释。现在把前面的通信过程使用数字证书修改为如下:

2.5 第五回合:

“客户”->“服务器”:你好
“服务器”->“客户”:你好,我是服务器,这里是我的数字证书        //这里用证书代替了公钥
“客户”->“服务器”:向我证明你就是服务器
“服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

注意,上面第二次通信,“服务器”把自己的证书发给了“客户”,而不是发送公钥。“客户”可以根据证书校验这个证书到底是不是“服务器”的,也就是能校验这个证书的所有者是不是“服务器”,从而确认这个证书中的公钥的确是“服务器”的。后面的过程和以前是一样,“客户”让“服务器”证明自己的身份,“服务器”用私钥加密一段内容连同明文一起发给“客户”,“客户”把加密内容用数字证书中的公钥解密后和明文对比,如果一致,那么对方就确实是“服务器”,然后双方协商一个对称加密来保证通信过程的安全。到这里,整个过程就完整了,我们回顾一下:

2.6 完整过程:

step1: “客户”向服务端发送一个通信请求
“客户”->“服务器”:你好
  
step2: “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息,私钥由“服务器”持有

“服务器”->“客户”:你好,我是服务器,这里是我的数字证书 

step3: “客户”收到“服务器”的证书后,它会去验证这个数字证书到底是不是“服务器”的,数字证书有没有什么问题,数字证书如果检查没有问题,就说明数字证书中的公钥确实是“服务器”的。检查数字证书后,“客户”会发送一个随机的字符串给“服务器”用私钥去加密,服务器把加密的结果返回给“客户”,“客户”用公钥解密这个返回结果,如果解密结果与之前生成的随机字符串一致,那说明对方确实是私钥的持有者,或者说对方确实是“服务器”。

“客户”->“服务器”:向我证明你就是服务器,这是一个随机字符串     //前面的例子中为了方便解释,用的是“你好”等内容,实际情况下一般是随机生成的一个字符串。

“服务器”->“客户”:{一个随机字符串}[私钥|RSA]

step4: 验证“服务器”的身份后,“客户”生成一个对称加密算法密钥,用于后面的通信的加密和解密。这个对称加密算法密钥,“客户”会用公钥加密后发送给“服务器”,别人截获了也没用,因为只有“服务器”手中有可以解密的私钥。这样,后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。

“服务器”->“客户”:{OK,已经收到你发来的对称加密算法和密钥!有什么可以帮到你的?}[密钥|对称加密算法]

“客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]

“服务器”->“客户”:{你好,你的余额是100元}[密钥|对称加密算法]

…… //继续其它的通信

2.7 其它问题:

上面的过程已经十分接近HTTPS的真实通信过程了,完全可以按照这个过程去理解HTTPS的工作原理。但是我为了方便解释,上面有些细节没有说到,有兴趣的人可以看下这部分的内容。可以跳过不看,无关紧要。

【问题1】

上面的通信过程中说到,在检查完证书后,“客户”发送一个随机的字符串给“服务器”去用私钥加密,以便判断对方是否真的持有私钥。但是有一个问题,“黑客”也可以发送一个字符串给“服务器”去加密并且得到加密后的内容,这样对于“服务器”来说是不安全的,因为黑客可以发送一些简单的有规律的字符串给“服务器”加密,从而寻找加密的规律,有可能威胁到私钥的安全。所以说,“服务器”随随便便用私钥去加密一个来路不明的字符串并把结果发送给对方是不安全的。

〖解决方法〗

每次收到“客户”发来的要加密的的字符串时,“服务器”并不是真正的加密这个字符串本身,而是把这个字符串进行一个hash计算,加密这个字符串的hash值(不加密原来的字符串)后发送给“客户”,“客户”收到后解密这个hash值并自己计算字符串的hash值然后进行对比是否一致。也就是说,“服务器”不直接加密收到的字符串,而是加密这个字符串的一个hash值,这样就避免了加密那些有规律的字符串,从而降低被破解的机率。“客户”自己发送的字符串,因此它自己可以计算字符串的hash值,然后再把“服务器”发送过来的加密的hash值和自己计算的进行对比,同样也能确定对方是否是“服务器”。

【问题2】

在双方的通信过程中,“黑客”可以截获发送的加密了的内容,虽然他无法解密这个内容,但是他可以捣乱,例如把信息原封不动的发送多次,扰乱通信过程。

〖解决方法〗

可以给通信的内容加上一个序号或者一个随机的值,如果“客户”或者“服务器”接收到的信息中有之前出现过的序号或者随机值,那么说明有人在通信过程中重发信息内容进行捣乱,双方会立刻停止通信。有人可能会问,如果有人一直这么捣乱怎么办?那不是无法通信了? 答案是的确是这样的,例如有人控制了你连接互联网的路由器,他的确可以针对你。但是一些重要的应用,例如军队或者政府的内部网络,它们都不使用我们平时使用的公网,因此一般人不会破坏到他们的通信。 

【问题3】

在双方的通信过程中,“黑客”除了简单的重复发送截获的消息之外,还可以修改截获后的密文修改后再发送,因为修改的是密文,虽然不能完全控制消息解密后的内容,但是仍然会破坏解密后的密文。因此发送过程如果黑客对密文进行了修改,“客户”和“服务器”是无法判断密文是否被修改的。虽然不一定能达到目的,但是“黑客”可以一直这样碰碰运气。

〖解决方法〗

在每次发送信息时,先对信息的内容进行一个hash计算得出一个hash值,将信息的内容和这个hash值一起加密后发送。接收方在收到后进行解密得到明文的内容和hash值,然后接收方再自己对收到信息内容做一次hash计算,与收到的hash值进行对比看是否匹配,如果匹配就说明信息在传输过程中没有被修改过。如果不匹配说明中途有人故意对加密数据进行了修改,立刻中断通话过程后做其它处理。

3. 证书的构成和原理
3.1 证书的构成和原理

之前已经大概说了一个证书由什么构成,但是没有仔细进行介绍,这里对证书的内容做一个详细的介绍。先看下一个证书到底是个什么东西,在windows下查看一个证书时,界面是这样的,我们主要关注一下Details Tab页,其中的内容比较长,我滚动内容后后抓了三个图,把完整的信息显示出来:

certificateDetails

里面的内容比较多——Version、Serial number、Signature algorithm 等等,挑几个重要的解释一下。

◆Issuer (证书的发布机构)

指出是什么机构发布的这个证书,也就是指明这个证书是哪个公司创建的(只是创建证书,不是指证书的使用者)。对于上面的这个证书来说,就是指”SecureTrust CA”这个机构。

◆Valid from , Valid to (证书的有效期)

也就是证书的有效时间,或者说证书的使用期限。 过了有效期限,证书就会作废,不能使用了。

◆Public key (公钥)

这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密的,第2章的例子中经常用到的。这个数字证书的公钥是2048位的,它的值可以在图的中间的那个对话框中看得到,是很长的一串数字。

◆Subject (主题)

这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。 对于这里的证书来说,证书的所有者是Trustwave这个公司。

◆Signature algorithm (签名所使用的算法)

就是指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。指纹的加密结果就是数字签名(第1.5节中解释过数字签名)。

◆Thumbprint, Thumbprint algorithm (指纹以及指纹算法)

这个是用来保证证书的完整性的,也就是说确保证书没有被修改过,这东西的作用和2.7中说到的第3个问题类似。 其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值对得上,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。 注意,这个指纹会使用”SecureTrust CA”这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起。

注意,为了保证安全,在证书的发布机构发布证书时,证书的指纹和指纹算法,都会加密后再和证书放到一起发布,以防有人修改指纹后伪造相应的数字证书。这里问题又来了,证书的指纹和指纹算法用什么加密呢?他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密,也就是说证书发布机构除了给别人发布证书外,他自己本身也有自己的证书。证书发布机构的证书是哪里来的呢???这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows xp等操作系统),这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了,微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构,把这些证书发布机构的证书默认就安装在操作系统里面了,并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥,他会用这个私钥加密所有他发布的证书的指纹作为数字签名。

3.2 如何向证书的发布机构去申请证书

举个例子方便大家理解,假设我们公司”ABC Company”花了1000块钱,向一个证书发布机构”SecureTrust CA”为我们自己的公司”ABC Company”申请了一张证书,注意,这个证书发布机构”SecureTrust CA”是一个大家公认并被一些权威机构接受的证书发布机构,我们的操作系统里面已经安装了”SecureTrust CA”的证书。”SecureTrust CA”在给我们发布证书时,把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面,然后用一个指纹算法计算出这些数字证书内容的一个指纹,并把指纹和指纹算法用自己的私钥进行加密,然后和证书的内容一起发布,同时”SecureTrust CA”还会给一个我们公司”ABC Company”的私钥给到我们。我们花了1000块钱买的这个证书的内容如下:

×××××××××××××××证书内容开始×××××××××××××××××
Issuer : SecureTrust CA
Subject : ABC Company
Valid from : 某个日期
Valid to: 某个日期
Public Key : 一串很长的数字
…… 其它的一些证书内容……

{证书的指纹和计算指纹所使用的指纹算法}[SecureTrust CA的私钥|RSA]      //这个就是”SecureTrust CA”对这个证书的一个数字签名,表示这个证书确实是他发布的,有什么问题他会负责(收了我们1000块,出了问题肯定要负责任的)

×××××××××××××××证书内容结束×××××××××××××××××

               // 记不记得前面的约定?{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密

我们”ABC Company”申请到这个证书后,我们把证书投入使用,我们在通信过程开始时会把证书发给对方,对方如何检查这个证书的确是合法的并且是我们”ABC Company”公司的证书呢?首先应用程序(对方通信用的程序,例如IE、OUTLook等)读取证书中的Issuer(发布机构)为”SecureTrust CA” ,然后会在操作系统中受信任的发布机构的证书中去找”SecureTrust CA”的证书,如果找不到,那说明证书的发布机构是个水货发布机构,证书可能有问题,程序会给出一个错误信息。 如果在系统中找到了”SecureTrust CA”的证书,那么应用程序就会从证书中取出”SecureTrust CA”的公钥,然后对我们”ABC Company”公司的证书里面的指纹和指纹算法用这个公钥进行解密,然后使用这个指纹算法计算”ABC Company”证书的指纹,将这个计算的指纹与放在证书中的指纹对比,如果一致,说明”ABC Company”的证书肯定没有被修改过并且证书是”SecureTrust CA” 发布的,证书中的公钥肯定是”ABC Company”的。对方然后就可以放心的使用这个公钥和我们”ABC Company”进行通信了。

★这个部分非常重要,一定要理解,您可以重新回顾一下之前的两章“1、基础知识”“ 2、一个加密通信过程的演化”,然后再来理解这部分的内容。如果您把这节的内容看了几遍还没有搞懂证书的工作原理,您可以留言指出我没有说清楚的内容,我好方便进行修正。

3.3 证书的发布机构

前面已经初步介绍了一下证书发布机构,这里再深入讨论一下。

其实所有的公司都可以发布证书,我们自己也可以去注册一家公司来专门给别人发布证书。但是很明显,我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的,人家怎么知道你是不是个狗屁皮包公司?因此微软在它的操作系统中,并不会信任我们这个证书发布机构,当应用程序在检查证书的合法信的时候,一看证书的发布机构并不是操作系统所信任的发布机构,就会抛出错误信息。也就是说windows操作系统中不会预先安装好我们这个证书发布机构的证书,不信任我们这个发布机构。

  
不受信任的证书发布机构的危害
为什么一个证书发布机构受不受信任这么重要?我们举个例子。假设我们开了一个狗屁公司来为别人发布证书,并且我和微软有一腿,微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫Wicrosoft 花了10块钱让我为他们公司申请了一个证书,并且公司慢慢壮大,证书的应用范围也越来越广。然后有个奸商的公司JS Company想冒充Wicrosoft,于是给了我¥10000,让我为他们颁布一个证书,但是证书的名字(Subject)要写Wicrosoft,假如我为了这¥10000,真的把证书给了他们,那么他们以后就可以使用这个证书来冒充Wicrosoft了。

如果是一个优秀的证书发布机构,比如你要向他申请一个名字叫Wicrosoft的证书,它会让你提供很多资料证明你确实可以代表Wicrosoft这个公司,也就是说他回去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。

  

到这里,你可能会想,TMD,那我们自己就不能发布证书吗?就一定要花钱去申请?当然不是,我们自己也可以成立证书发布机构,但是需要通过一些安全认证等等,只是有点麻烦。另外,如果数字证书只是要在公司内部使用,公司可以自己给自己生成一个证书,在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书(这句话仔细看清楚,有点绕口),这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了(在发布证书时,把这些证书的Issuer(发布机构)设置为我们自己的证书发布机构的证书的Subject(主题)就可以了)。但是这只限于内部应用,因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构,而其它机器上并没有事先信任我们这个证书发布机构,所以在其它机器上,我们发布的证书就无法通过安全验证。

4. 在windows中对数字证书进行管理
4.1 查看、删除、安装 数字证书

我们在上一章中说到了,我们的操作系统中会预先安装好一些证书发布机构的证书,我们看下在windows中如何找到这些证书,步骤如下:

1)开始菜单->运行,输入mmc,回车
2)在打开的窗口中选择 File-> Add/Remove Snap-in…
3)然后在弹出的对话框的 Standalone Tab页里面点击 Add… 按钮
4)在弹出的对对话框中选择 certificates 后点击 Add 按钮
具体的步骤如下图所示:

上面的步骤结束后,会又弹出一个对话框,里面有三个单选按钮如下:

  • My user account
  • Service account
  • Computer account

可以选择第一或者第三个选项,用来查看当前用户的证书或整个计算里面安装的证书。我们这里就默认选择第一个,平时一般安装证书的时候都会给所有用户安装,所以选择第一个和第三个选项看到的证书会差不多。我们在左边的导航树中选中受信任的证书发布机构(Trusted Root Certificate Authorities),然后点击下面的证书(Certificates),在右边的区域中就可以看到所有的受信任的证书发布机构的证书。

trustedcaAuth

注意上面的图片中,右边我们选中的这个证书发布机构”SecureTrust CA”,我们前面在第3章3.2节中举例子的时候,就是去向这个证书发布机构申请的证书,由于我们申请的证书是这个机构发布的,所以应用程序在检查我们的证书的发布机构时(会检查我们证书的签名,确认是该机构发布的证书),就会发现是可以信任的证书发布机构,从而就会相信我们证书的真实性。

删除数字证书很简单,直接在右边的列表中右键然后删除就可以了。

数字证书的安装也比较简单,直接双击数字证书文件,会打开数字证书,对话框下面会有一个Install Certificate按钮,点击后就可以根据向导进行安装,如下图所示:

installCertificate

这个证书是我自己生成的测试证书,在证书的导入向导里面,它会让你选择导入到什么位置,如果是一个我们自己信任的证书发布机构自己的证书,只要导入到Certificate Authorities就可以了。Trusted Root Certificate Authorities, Intermediate Certification Authorities, Third-Party Root Certification Authorities 都是可以的,他们只是对证书的发布机构做了一个分类,还有一些其它的证书类型,例如Personal(个人证书)等等,具体就不介绍了。安装的时候一般来说可以用默认的选择项一直”下一步”到底。

4.2 如何自己创建证书

每个证书发布机构都有自己的用来创建证书的工具,当然,具体他们怎么去创建一个证书的我也不太清楚,不同类型的证书都有一定的格式和规范,我没有仔细去研究过这部分内容。 微软为我们提供了一个用来创建证书的工具makecert.exe,在安装Visual Studio的时候会安装上。如果没有安装也无所谓,可以上网去下一个,搜索makecert就可以了。可以直接从我的博客下载,这是链接

向一些正规的证书发布机构申请证书一般是要收费的(因为别人要花时间检查你的身份,确认有没有同名的证书等等),这里我们看下如何自己创建一个证书,为后面在IIS中配置Https做准备。

我们用到的是makecert这个工具,微软有很详细的使用帮助,我这里只做一个简单的解释,详细的各种参数和使用方法请查看MSDN的makecert的帮助。但是里面有些参数说得不够清楚,而且还有遗漏的,可以参看我后面的解释作为一个补充。

先看下makecert最简单的使用方式:

makecert.exe test.cer

上面的命令会在makecert.exe所在的目录生成一个证书文件test.cer的数字证书文件。可以双击证书打开,看看证书的内容如下:

testCertificate1

证书的发布机构是”Root Agency”,证书的主题(证书发布给谁)是”Joe’s-Software-Emporium”,因为我们没有指定把证书发布给谁,makecert自己给我们随便生成了一个公司的名字。另外还指定了公钥、签名算法(用来解密签名)、指纹和指纹算法等。

注意,因为这个证书是由微软的工具生成的,严格来说它没什么发布机构,所以微软虚拟了一个叫做”Root Agency”的发布机构,默认情况下,windows里面安装了这个所谓的证书发布机构的证书,但是这证书默认情况下不是受信任的,原因很简单,这样做大家都可以用makecert来制作合法的数字证书了。如果我们自己硬是要,也可以把它设置为受信任的。

下面我们看下其它的参数,比如我们要给网站 www.jefferysun.com 生成一个证书MyCA.cer,假设我们把makecert.exe放在C:盘下,命令行如下:

makecert -r -pe -n “CN=10.30.146.206″ -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp “Microsoft RSA SChannel Cryptographic Provider” -sy 12

C:\> makecert.exe –pe -r  –n  “CN=www.jefferysun.com” -ss my -sr LocalMachine -a sha1 -len 2048  MyCA.cer

解释一下makecert的常用参数的意思:

  • -n 指定主题的名字,这个是有固定的格式的, CN=主题名字 ,CN应该是Certificate Name的缩写。我这里的主题的名字就是我们的IIS所在机器的IP。这里可以指定一些主题的其它附加信息,例如 O= *** 表示组织信息等等。
  • -r 创建自签署证书,意思就是说在生成证书时,将证书的发布机构设置为自己。
  • -pe 将所生成的私钥标记为可导出。注意,服务器发送证书给客户端的时候,客户端只能从证书里面获取公钥私钥是无法获取的。如果我们指定了这个参数,证书在安装在机器上后,我们还可以从证书中导出私钥,默认情况下是不能导出私钥的。正规的途径发布的证书,是不可能让你导出私钥的。
  • -b –e 证书的有效期
  • -ss 证书的存储名称,就是windows证书存储区的目录名,如果不存在在的话就创建一个。
  • -sr 证书的存储位置,只有currentuser(默认值)或 localmachine两个值。
  • -sv 指定保存私钥的文件,文件里面除了包含私钥外,其实也包含了证书。这个文件是需要保密的,这个文件在服务端配置时是需要用到的。
  • 这个CN=10.30.146.206要与自己的服务器相对应,要不然在配置HTTPS的时候会出现错误
  • -a 指定签名算法,必须是md5或rsa1。(还记得签名算法的作用不?可以看一下3章的第1节中关于签名算法的介绍)
  • -in 指定证书发布机构的名称
  • -len 这个参数在中文的帮助文档中好像没有提到,但是这个其实很重要,用于指定公钥的位数,越大越安全,默认值是1024,推荐2048。我试了下,这个不为1024的倍数也是可以的。

生成证书后可以进行安装,安装过程可以参看4.1节。

本文链接:http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html

Posted in 系统开发 | Leave a comment

MySQL Memory Allocation

MySQL Memory Allocation

Table of Contents

Allocating RAM for MySQL – The Short Answer
What is the key_buffer?
What is the buffer_pool?
Another algorithm
Mutex bottleneck
HyperThreading and Multiple cores (CPUs)
32-bit OS and MySQL
64-bit OS with 32-bit MySQL
64-bit OS and MySQL
max_connections, thread_stack
table_cache (table_open_cache)
Query Cache
thread_cache_size
Binary Logs
swappiness
NUMA
huge pages
ENGINE=MEMORY
How to Set VARIABLEs
Web server
Tools
Postlog
Brought to you by Rick James

Allocating RAM for MySQL – The Short Answer

If using just MyISAM, set key_buffer_size to 20% of _available_ RAM. (Plus innodb_buffer_pool_size=0)

If using just InnoDB, set innodb_buffer_pool_size to 70% of _available_ RAM. (Plus key_buffer_size = 10M, small, but not zero.)

Rule of thumb for tuning mysql:
⚈ Start with released copy of my.cnf / my.ini.
⚈ Change key_buffer_size and innodb_buffer_pool_size according to engine usage and RAM.
⚈ Slow queries can usually be ‘fixed’ via indexes, schema changes, or SELECT changes, not by tuning.
⚈ Don’t get carried away with the Query cache until you understand what it can and cannot do.
⚈ Don’t change anything else unless you run into trouble (eg, max connections).
⚈ Be sure the changes are under the [mysqld] section, not some other section.

Now for the gory details. (NDB Cluster is not discussed here.)in

What is the key_buffer?

MyISAM does two different things for caching.
⚈ Index blocks (1KB each, BTree structured, from .MYI file) live in the “key buffer”.
⚈ Data block caching (from .MYD file) is left to the OS, so be sure to leave a bunch of free space for this.
Caveat: Some flavors of OS always claim to be using over 90%, even when there is really lots of free space.

SHOW GLOBAL STATUS LIKE ‘Key%’; then calculate Key_read_requests / Key_reads If it is high (say, over 10), then the key_buffer is big enough.

What is the buffer_pool?

InnoDB does all its caching in a the “buffer pool”, whose size is controlled by innodb_buffer_pool_size. It contains 16KB data and index blocks from the open tables, plus some maintenance overhead.

MySQL 5.5 (and 5.1 with the “Plugin”) lets you declare the block size to be 8KB or 4KB. MySQL 5.5 allows multiple buffer pools; this can help because there is one mutex per pool, thereby relieving some of the Mutex bottleneck.

More on InnoDB Tuning

Another algorithm

This will set the main cache settings to the minimum; it could be important to systems with lots of other processes and/or RAM is 2GB or smaller.

Do SHOW TABLE STATUS for all the tables in all the databases.

Add up Index_length for all the MyISAM tables. Set key_buffer_size no larger than that size.

Add up Data_length + Index_length for all the InnoDB tables. Set innodb_buffer_pool_size to no more than 110% of that total.

If that leads to swapping, cut both settings back. Suggest cutting them down proportionately.

Run this to see the values for you system. (If you have a lot of tables, it can take minute(s).)
SELECT ENGINE,
ROUND(SUM(data_length) /1024/1024, 1) AS “Data MB”,
ROUND(SUM(index_length)/1024/1024, 1) AS “Index MB”,
ROUND(SUM(data_length + index_length)/1024/1024, 1) AS “Total MB”,
COUNT(*) “Num Tables”
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema not in (“information_schema”, “performance_schema”)
GROUP BY ENGINE;

Mutex bottleneck

MySQL was designed in the days of single-CPU machines, and designed to be easily ported to many different architectures. Unfortunately, that lead to some sloppiness in how to interlock actions. There are small number (too small) of “mutexes” to gain access to several critical processes. Of note:
⚈ MyISAM’s key_buffer
⚈ The Query Cache
⚈ InnoDB’s buffer_pool
With multi-core boxes, the mutex problem is causing performance problems. In general, past 4-8 cores, MySQL gets slower, not faster. MySQL 5.5 and Percona’s XtraDB are making that somewhat better in InnoDB; the practical limit for cores is more like 32, and performance tends plateaus after that rather than declining. 5.6 claims to scale up to about 48 cores.

HyperThreading and Multiple cores (CPUs)

Short answers:
⚈ Turn off HyperThreading
⚈ Turn off any cores beyond 8
⚈ HyperThreading is mostly a thing of the past, so this section may not apply.

HyperThreading is great for marketing, lousy for performance. It involves having two processing units sharing a single hardware cache. If both units are doing the same thing, the cache will be reasonably useful. If the units are doing different things, they will be clobbering each other’s cache entries.

Furthermore MySQL is not great on using multiple cores. So, if you turn off HT, the remaining cores run a little faster.

32-bit OS and MySQL

First, the OS (and the hardware?) may conspire to not let you use all 4GB, if that is what you have. If you have more than 4GB of RAM, the excess beyond 4GB is _totally_ inaccessable and unusable on a 32-bit OS.

Secondly, the OS probably has a limit on how much RAM it will allow any process to use.

Example: FreeBSD’s maxdsiz, which defaults to 512MB.

Example:
$ ulimit -a

max memory size (kbytes, -m) 524288

So, once you have determined how much RAM is available to mysqld, then apply the 20%/70%, but round down some.

If you get an error like [ERROR] /usr/libexec/mysqld: Out of memory (Needed xxx bytes), it probably means that MySQL exceeded what the OS is willing to give it. Decrease the cache settings.

64-bit OS with 32-bit MySQL

The OS is not limited by 4GB, but MySQL is.

If you have at least 4GB of RAM, then maybe these would be good:
⚈ key_buffer_size = 20% of _all_ of RAM, but not more than 3G
⚈ buffer_pool = 3G

You should probably upgrade MySQL to 64-bit.

64-bit OS and MySQL

MyISAM only: key_buffer_size (before 5.0.52 / 5.1.23) had a hard limit of 4G. See also 5.1 restrictions
Otherwise, use about 20% of RAM. Set (in my.cnf / my.ini) innodb_buffer_pool_size = 0.

InnoDB only: innodb_buffer_pool_size = 70% of RAM. If you have lots of RAM and are using 5.5 (or later), then consider having multiple pools. Recommend 1-16 innodb_buffer_pool_instances, such that each one is no smaller than 1GB. (Sorry, no metric on how much this will help; probably not a lot.)

Meanwhile, set key_buffer_size = 20M (tiny, but non-zero)

If you have a mixture of engines, lower both numbers.

max_connections, thread_stack

Each “thread” takes some amount of RAM. This used to be about 200KB; 100 threads would be 20MB, not a signifcant size. If you have max_connections = 1000, then you are talking about 200MB, maybe more. Having that many connections probably implies other issues that should be addressed.

In 5.6 (or MariaDB 5.5), optional thread pooling interacts with max_connections. This is a more advanced topic.

Thread stack overrun rarely happens. If it does, do something like thread_stack=256K

More on max_connections, wait_timeout, connection pooling, etc

table_cache (table_open_cache)

(The name changed in some version.)

The OS has some limit on the number of open files it will let a process have. Each table needs 1 to 3 open files. Each PARTITION is effectively a table. Most operations on a partitioned table open _all_ partitions.

In *nix, ulimit tells you what the file limit is. The maximum value is in the tens of thousands, but sometimes it is set to only 1024. This limits you to about 300 tables. More discussion on ulimit

(This paragraph is in disputed.) On the other side, the table cache is (was) inefficiently implemented — lookups were done with a linear scan. Hence, setting table_cache in the thousands could actually slow down mysql. (Benchmarks have shown this.)

You can see how well your system is performing via SHOW GLOBAL STATUS; and computing the opens/second via Opened_files / Uptime If this is more than, say, 5, table_cache should be increased. If it is less than, say, 1, you might get improvement by decreasing table_cache.

Query Cache

Short answer: query_cache_type = OFF and query_cache_size = 0

The QC is effectively a hash mapping SELECT statements to resultsets.

Long answer… There are many aspects of the “Query cache”; many are negative.
⚈ Novice Alert! The QC is totally unrelated to the key_buffer and buffer_pool.
⚈ When it is useful, the QC is blazingly fast. It would not be hard to create a benchmark that runs 1000x faster.
⚈ There is a single mutex controlling the QC.
⚈ The QC, unless it is OFF & 0, is consulted for _every_ SELECT.
⚈ Yes, the mutex is hit even if query_cache_type = DEMAND (2).
⚈ Yes, the mutex is hit even for SQL_NO_CACHE.
⚈ Any change to a query (even adding a space) leads (potentially) to a different entry in the QC.

“Pruning” is costly and frequent:
⚈ When _any_ write happens on a table, _all_ entries in the QC for _that_ table are removed.
⚈ It happens even on a readonly Slave.
⚈ Purges are performed with a linear algorithm, so a large QC (even 200MB) can be noticeably slow.

To see how well your QC is performing, SHOW GLOBAL STATUS LIKE ‘Qc%’; then compute the read hit rate: Qcache_hits / Qcache_inserts If it is over, say, 5, the QC might be worth keeping.

If you decide the QC is right for you, then I recommend
⚈ query_cache_size = no more than 50M
⚈ query_cache_type = DEMAND
⚈ SQL_CACHE or SQL_NO_CACHE in all SELECTs, based on which queries are likely to benefit from caching.

QC in depth

thread_cache_size

This is a minor tunable. Zero will slow down thread (connection) creation. A small (say, 10), non-zero number is good. The setting has essentially no impact on RAM usage.

It is the number of extra processes to hang onto. It does not restrict the number of threads; max_connections does.

Binary Logs

If you have turned on binarly loging (via log_bin) for replication and/or point-in-time recovery, The system will create binary logs forever. That is, they can slowly fill up disk. Suggest setting expire_logs_days = 14 to keep only 14 days’ worth of logs.

swappiness

RHEL, in its infinite wisdom, decided to let you control how aggressively the OS will preemptively swap RAM. This is good in general, but lousy for MySQL.

MySQL would love for RAM allocations to be reasonably stable — the caches are (mostly) pre-allocated; the threads, etc, are (mostly) of limited scope. ANY swapping is likely to severly hurt performance of MySQL.

With a high value for swappiness, you lose some RAM because the OS is trying to keep a lot of space free for future allocations (that MySQL is not likely to need).

With swappiness = 0, the OS will probably crash rather than swap. I would rather have MySQL limping than die.

Somewhere in between (say, 5?) might be a good value for a MySQL-only server.

NUMA

OK, it’s time to complicate the architecture of how a CPU talks to RAM. NUMA (Non-Uniform Memory Access) enters the picture. Each CPU (or maybe socket with several cores) has a part of the RAM hanging off each. This leads to memory access being faster for local RAM, but slower (tens of cycles slower) for RAM hanging off other CPUs.

Then the OS enters the picture. In at least one case (RHEL?), two things seem to be done:
⚈ OS allocations are pinned to the ‘first’ CPU’s RAM.]
⚈ Other allocations go by default to the first CPU until it is full.

Now for the problem.
⚈ The OS and MySQL have allocated all the ‘first’ RAM.
⚈ MySQL has allocated some of the second RAM.
⚈ The OS needs to allocate something.
Ouch — it is out of room in the one CPU where it is willing to allocate its stuff, so it swaps out some of MySQL. Bad.

Possible solution: Configure the BIOS to “interleave” the RAM allocations. This should prevent the premature swapping, at the cost of off-CPU RAM accesses half the time. Well, you have the costly accesses anyway, since you really want to use all of RAM.

Overall performance loss/gain: A few percent.

huge pages

This is another hardware performance gimmick.

For a CPU to access RAM, especially mapping a 64-bit address to somewhere in, say, 128GB or ‘real’ RAM, the TLB is used. (TLB = Translation Lookup Buffer.) Think of the TLB as a hardware associative memory lookup table; given a 64-bit virtual address, what is the real address.

Because it is an associative memory of finite size, sometimes there will be “misses” that require reaching into real RAM to resolve the lookup. This is costly, so should be avoided.

Normally, RAM is ‘paged’ in 4KB pieces; the TLB actually maps the top (64-12) bits into a specific page. Then the bottom 12 bits of the virtual address are carried over intact.

For example, 128GB of RAM broken 4KB pages means 32M page-table entries. This is a lot, and probably far exceeds the capacity of the TLB. So, enter the “Huge page” trick.

With the help of both the hardware and the OS, it is possible to have some of RAM in huge pages, of say 4MB (instead of 4KB). This leads to far fewer TLB entries, but it means the unit of paging is 4MB for such parts of RAM. Hence, huge pages tend to be non-pagable.

Now RAM is broken into pagable and non pagable parts; what parts can reasonably be non pagable? In MySQL, the innodb_buffer_pool is a perfect candidate. So, by correctly configuring these, InnoDB can run a little faster:
Huge pages enabled
⚈ Tell the OS to allocate the right amount (namely to match the buffer_pool)
⚈ Tell MySQL to use huge pages

innodb memory usage vs swap
That thread has more details on what to look for and what to set.

Overall performance gain: A few percent. Yawn.

ENGINE=MEMORY

This is a little-used alternative to MyISAM and InnoDB. The data is not persistent, so it has limited uses. The size of a MEMORY table is limited to max_heap_table_size, which defaults to 16MB. I mention it in case you have changed the value to something huge; this would stealing from other possible uses of RAM.

How to Set VARIABLEs

In the text file my.cnf (my.ini on Windows), add more modify a line to say something like
innodb_buffer_pool_size = 5G
That is, VARIABLE name, “=”, and a value. Some abbreviations are allowed, such as M for million (1048576), G for billion.

For the server to see it, the settings must be in the “[mysqld]” section of the file.

The settings in my.cnf or my.ini will not take effect until you restart the server.

Most settings can be changed on the live system by connecting as user root (or other user with SUPER privilege) and doing something like
SET @@global.key_buffer_size = 77000000;
Note: No M or G suffix is allowed here.

To see the setting a global VARIABLE do something like
mysql> SHOW GLOBAL VARIABLES LIKE “key_buffer_size”;
+—————–+———-+
| Variable_name | Value |
+—————–+———-+
| key_buffer_size | 76996608 |
+—————–+———-+
Note that this particular setting was rounded down to some multiple that MySQL liked.

You may want to do both (SET, and modify my.cnf) in order to make the change immediately and have it so that the next restart (for whatever reason) will again get the value.

Web server

A web server like Apache runs multiple threads. If each threads opens a connection to MySQL, you could run out of connections. Make sure MaxClients (or equivalent) is set to some civilized number (under 50).

Tools

MySQLTuner
⚈ TUNING-PRIMER

There are several tools that advise on memory. One misleading entry they come up with
Maximum possible memory usage: 31.3G (266% of installed RAM)
Don’t let it scare you — the formulas used are excessively conservative. They assume all of max_connections are in use and active, and doing something memory-intensive.

Total fragmented tables: 23 This implies that OPTIMIZE TABLE _might_ help. I suggest it for tables with either a high percentage of “free space” (see SHOW TABLE STATUS) or where you know you do a lot of DELETEs and/or UPDATEs. Still, don’t bother to OPTIMIZE too often. Once a month might suffice.

Postlog

Created 2010; Refreshed Oct, 2012, Jan, 2014

More in-depth: Tocker’s tuning for 5.6
Irfan’s InnoDB performance optimization basics (redux)
10 MySQL settings to tune after installation

Contact me by posting a question at MySQL Forums :: Performance
– Rick James

MySQL Documents by Rick James

Tips, Debugging, HowTos, Optimizations, etc…

Rick’s RoTs (Rules of Thumb — lots of tips)
Memory Allocation (caching, etc)
Character Set and Collation problem solver
Converting from MyISAM to InnoDB — includes differences between them
Big DELETEs – how to optimize
Compound INDEXes plus other insights into the mysteries of INDEXing
Partition Maintenance (DROP+REORG) for time series
Entity-Attribute-Value — a common, poorly performing, design patter; plus an alternative
Find the nearest 10 pizza parlors (efficient searching on Latitude + Longitude)
Alter of a Huge table
Latest 10 news articles — how to optimize the schema and code for such
Pagination, not with OFFSET, LIMIT
Data Warehouse techniques (esp., Summary Tables)
Techniques on efficiently finding a random row (On beyond ORDER BY RAND())
GUID/UUID Performance (type 1 only)
IP Range Table Performance
MySQL Limits
Galera Limitations (with Percona XtraDB Cluster / MariaDB)
Rollup Unique User Counts
Best of MySQL Forum

原文地址:
mysql.rjweb.org/doc.php/memory

Posted in MySQL | Tagged | Leave a comment

最近的生活 2014-07-25

最近总觉得时间过的很快,一眨眼一个周就过去了,有很多事情来不急去做。每天起床、吃饭、上班、下班、睡觉,要看书只能够在上下班的地铁上了,不过就靠着这挤出来的时间,倒也看完了几本书了,我是标准的不求甚解者,看完的东西隔个几天就记忆不清了,真想拥有过目不忘的本事啊。
最近换了手机,老的G2手机太慢了,好多的软件都运行不起来,现在用手机订阅了一些博客,在手机多看上也买了几本书,现在在吃饭的间隙、等车的时候…都翻翻看看,人呀,总要找些事情做。
说起学习,刚看完了《深入理解jvm虚拟机》《java虚拟机原理》,《mysql技术内幕.innodb存储引擎》。看得时候觉得嗯嗯嗯,然后过几天就忘记了,回过头来看又觉得是啊,是要这么实现,然后过几天又记不清了。唉,纸上得来终是浅啊,得亲自搞搞才行,前些天自己编译了jdk,打算参考着代码看看,还有innodb的代码,不过c,c++不熟悉啊,希望在看的同时再学习下她。毕竟还是必要的。要学的东西太多了…年纪大了…
朋友也少联系了…

–EOF-

Posted in 猿の生活 | Leave a comment

工程师的生活

工程师的生活
http://www.raychase.net/1543

    我忽然很好奇,想知道其他软件工程师的生活是什么样的?人永远都没有活在别人心中的形象那么绚烂,生活中总有无数烂事烦事需要处理,但是每个人都有自己享受生活的方式。逛了逛了各式技术博客和论坛,我发现大家似乎都太严肃了,太谦逊了,太学术了。做软件本来是一件很有意思的事情,但是这些帖子和文章无非就包括这么几种:
    1、技术文章,不解释,这部分当然是大头,虽然技术文章普遍不受欢迎;
    2、牢骚,喵了个咪的薪水低啊,呜了个汪的加班苦啊;
    3、心灵鸡汤,要励志、要发奋、要改变世界;
长者语气教育后辈,“给刚入职的程序员们的警示”;
    4、无聊的纷争,Linux就是比Windows牛逼,Java就是一门屎尿屁的语言……
    做软件的人只是如此吗?就只有上面这几条单调的事情可以聊?工程师就不能记录更丰富的生活吗?在大多数人都在谈论生活品质的时候,工程师也应该跟上脚步。我相信Geek的生活有人羡慕也只能算少数,码农的生活虽司空见惯但他们才是最大的群体,才是软件行业未来的希望。既然没有任何人提及软件工程师的生活品质,那我愿意做第一个吃螃蟹的人:
成为工程师,而不是码农。如果你连这样的愿望都没有,我们的不同点太多,就算我白啰嗦了。
    寻找不同的享乐方式。为什么把享受放在那么靠前的位置?不是说要先奋斗后享乐吗?这样想的话,说不定你已经被洗过脑了。你的成功不会和享乐冲突的,每个人都可以选择自己的生活方式,谁都有自己的衡量标准,但是在我看来,只有在苦中坚持而不会作乐的生活才是百分百失败的。
     为你和你自己的梦想而工作。不要单纯为公司而工作,也不要只是为父母而工作。知道得少不可怕,可怕的是知道的都是被洗脑了的。容许其他人说那些大道理,容许那些心灵鸡汤天天试图灌你喝,自己千万要清醒,要对自己负责。那些为了公司而拼了命的人,并不是你的榜样。前两天看到一条评论根深蒂固加班文化的奴才机制,过度工作导致又有某某人猝死,却有大部分回复是在说“请注意锻炼一下”,这让我感到无比悲哀和寒心,这里的问题是“锻炼”不够的问题么?
    尊重、容忍和改变。我在《致那些自嘲码农的苦逼程序员》里面已经说过了,我们都理解那些迫不得已的事情,隐忍是在等待时机,蛰伏是有明确目的的,是为了冲破现状,追寻更接近理想和价值观的生活。最怕的事情是,在这样自己都不愿认可的生活中,磨平了棱角。
    积极争取想要的一切。我不想泡心灵鸡汤,因为我只是想说那些小事。就像你想要“一台大屏幕的显示器”这样的事情一样,如果它当然可以大大地提高你的工作品质,没有什么太明显不过的迹象阻挠你,为什么不争取一下?会失败还是成功?至少争取过了,不会有一点遗憾。我有一位欧洲的同事,它给公司的后勤部门提了不少意见建议,于是我们有了咖啡机、饮料有了更多的选品,灯管坏了能得到及时修理。还有一件小事,我的同事在飞机上被冷气吹得不舒服,提出来,没费多少口舌,得到了五千个里程的补偿。如果不屑去做、无所谓、有顾虑、懒得动弹,那就什么都不会有的。
    过酷一点的生活,还有自由的生活。你会有你自己的理解,比如西乔所说的“我在过着很奢侈的生活”,这绝不仅仅是只物质上(事实上她认为程序员还算是“收入能和付出成正比的群体”)。我可以以我自己为例,生活在北京但是我和我老婆远没有足够的钱,去买北京令我们方便和舒适的房子,那么我们就先不买,她每周都去练瑜伽,我每周都会打球,周末可以看电影、享受美食、学自己感兴趣的东西。我们还收养(主要是她在照顾)了两只无家可归的小狗(刚来的时候大概眼睛刚睁开,只能吃奶粉,现在已经会疯跑和到处乱啃了),等它们再大一点的时候可以把它们送到好一点的人家里去当宠物(如果你也在北京且感兴趣的话请联系我,邮件地址在右上角“关于四火”里有),我觉得这很酷。

Posted in 猿の生活 | Leave a comment

Netty系列之Netty可靠性分析

1. 背景

1.1. 宕机的代价

1.1.1. 电信行业

毕马威国际(KPMG International)在对46个国家的74家运营商进行调查后发现,全球通信行业每年的收益流失约为400亿美元,占总收入的1%-3%。导致收益流失的因素有多种,主要原因就是计费BUG。

1.1.2. 互联网行业

美国太平洋时间8月16日下午3点50分到3点55分(北京时间8月17日6点50分到6点55分),谷歌遭遇了宕机。根据事后统计,短短的5分钟,谷歌损失了54.5万美元。也就是服务每中断一分钟,损失就达10.8万美元。

2013年,从美国东部时间8月19日下午2点45分开始,有用户率先发现了亚马逊网站出现宕机,大约在20多分钟后又恢复正常。此次宕机让亚马逊每分钟损失近6.7万美元,在宕机期间,消费者无法通过Amazon.com、亚马逊移动端以及Amazon.ca等网站进行购物。

1.2. 软件可靠性

软件可靠性是指在给定时间内,特定环境下软件无错运行的概率。软件可靠性包含了以下三个要素:

1) 规定的时间:软件可靠性只是体现在其运行阶段,所以将运行时间作为规定的时间的度量。运行时间包括软件系统运行后工作与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性,软件的失效为随机事件,所以运行时间属于随机变量;

2) 规定的环境条件:环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素,如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说,规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求,并假定其它一切因素都是理想的。有了明确规定的环境条件,还可以有效判断软件失效的责任在用户方还是提供方;

3) 规定的功能:软件可靠性还与规定的任务和功能有关。由于要完成的任务不同,软件的运行剖面会有所区别,则调用的子模块就不同(即程序路径选择不同),其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。

1.3. Netty的可靠性

首先,我们要从Netty的主要用途来分析它的可靠性,Netty目前的主流用法有三种:

1) 构建RPC调用的基础通信组件,提供跨节点的远程服务调用能力;

2) NIO通信框架,用于跨节点的数据交换;

3) 其它应用协议栈的基础通信组件,例如HTTP协议以及其它基于Netty开发的应用层协议栈。

以阿里的分布式服务框架Dubbo为例,Netty是Dubbo RPC框架的核心。它的服务调用示例图如下:

图1-1 Dubbo的节点角色说明图

其中,服务提供者和服务调用者之间可以通过Dubbo协议进行RPC调用,消息的收发默认通过Netty完成。

通过对Netty主流应用场景的分析,我们发现Netty面临的可靠性问题大致分为三类:

1) 传统的网络I/O故障,例如网络闪断、防火墙Hang住连接、网络超时等;

2) NIO特有的故障,例如NIO类库特有的BUG、读写半包处理异常、Reactor线程跑飞等等;

3) 编解码相关的异常。

在大多数的业务应用场景中,一旦因为某些故障导致Netty不能正常工作,业务往往会陷入瘫痪。所以,从业务诉求来看,对Netty框架的可靠性要求是非常的高。作为当前业界最流行的一款NIO框架,Netty在不同行业和领域都得到了广泛的应用,它的高可靠性已经得到了成百上千的生产系统检验。

Netty是如何支持系统高可靠性的?下面,我们就从几个不同维度出发一探究竟。

2. Netty高可靠性之道

2.1. 网络通信类故障

2.1.1. 客户端连接超时

在传统的同步阻塞编程模式下,客户端Socket发起网络连接,往往需要指定连接超时时间,这样做的目的主要有两个:

1) 在同步阻塞I/O模型中,连接操作是同步阻塞的,如果不设置超时时间,客户端I/O线程可能会被长时间阻塞,这会导致系统可用I/O线程数的减少;

2) 业务层需要:大多数系统都会对业务流程执行时间有限制,例如WEB交互类的响应时间要小于3S。客户端设置连接超时时间是为了实现业务层的超时。

JDK原生的Socket连接接口定义如下:

图2-1 JDK Socket连接超时接口

对于NIO的SocketChannel,在非阻塞模式下,它会直接返回连接结果,如果没有连接成功,也没有发生IO异常,则需要将SocketChannel注册到Selector上监听连接结果。所以,异步连接的超时无法在API层面直接设置,而是需要通过定时器来主动监测。

下面我们首先看下JDK NIO类库的SocketChannel连接接口定义:

图2-2 JDK NIO 类库SocketChannel连接接口

从上面的接口定义可以看出,NIO类库并没有现成的连接超时接口供用户直接使用,如果要在NIO编程中支持连接超时,往往需要NIO框架或者用户自己封装实现。

下面我们看下Netty是如何支持连接超时的,首先,在创建NIO客户端的时候,可以配置连接超时参数:

图2-3 Netty客户端创建支持设置连接超时参数

设置完连接超时之后,Netty在发起连接的时候,会根据超时时间创建ScheduledFuture挂载在Reactor线程上,用于定时监测是否发生连接超时,相关代码如下:

图2-4 根据连接超时创建超时监测定时任务

创建连接超时定时任务之后,会由NioEventLoop负责执行。如果已经连接超时,但是服务端仍然没有返回TCP握手应答,则关闭连接,代码如上图所示。

如果在超时期限内处理完成连接操作,则取消连接超时定时任务,相关代码如下:

图2-5 取消连接超时定时任务

Netty的客户端连接超时参数与其它常用的TCP参数一起配置,使用起来非常方便,上层用户不用关心底层的超时实现机制。这既满足了用户的个性化需求,又实现了故障的分层隔离。

2.1.2. 通信对端强制关闭连接

在客户端和服务端正常通信过程中,如果发生网络闪断、对方进程突然宕机或者其它非正常关闭链路事件时,TCP链路就会发生异常。由于TCP是全双工的,通信双方都需要关闭和释放Socket句柄才不会发生句柄的泄漏。

在实际的NIO编程过程中,我们经常会发现由于句柄没有被及时关闭导致的功能和可靠性问题。究其原因总结如下:

1) IO的读写等操作并非仅仅集中在Reactor线程内部,用户上层的一些定制行为可能会导致IO操作的外逸,例如业务自定义心跳机制。这些定制行为加大了统一异常处理的难度,IO操作越发散,故障发生的概率就越大;

2) 一些异常分支没有考虑到,由于外部环境诱因导致程序进入这些分支,就会引起故障。

下面我们通过故障模拟,看Netty是如何处理对端链路强制关闭异常的。首先启动Netty服务端和客户端,TCP链路建立成功之后,双方维持该链路,查看链路状态,结果如下:

图2-6 Netty服务端和客户端TCP链路状态正常

强制关闭客户端,模拟客户端宕机,服务端控制台打印如下异常:

图2-7 模拟TCP链路故障

从堆栈信息可以判断,服务端已经监控到客户端强制关闭了连接,下面我们看下服务端是否已经释放了连接句柄,再次执行netstat命令,执行结果如下:

图2-8 查看故障链路状态

从执行结果可以看出,服务端已经关闭了和客户端的TCP连接,句柄资源正常释放。由此可以得出结论,Netty底层已经自动对该故障进行了处理。

下面我们一起看下Netty是如何感知到链路关闭异常并进行正确处理的,查看AbstractByteBuf的writeBytes方法,它负责将指定Channel的缓冲区数据写入到ByteBuf中,详细代码如下:

图2-9 AbstractByteBuf的writeBytes方法

在调用SocketChannel的read方法时发生了IOException,代码如下:

图2-10 读取缓冲区数据发生IO异常

为了保证IO异常被统一处理,该异常向上抛,由AbstractNioByteChannel进行统一异常处理,代码如下:

图2-11 链路异常退出异常处理

为了能够对异常策略进行统一,也为了方便维护,防止处理不当导致的句柄泄漏等问题,句柄的关闭,统一调用AbstractChannel的close方法,代码如下:

图2-12 统一的Socket句柄关闭接口

2.1.3. 正常的连接关闭

对于短连接协议,例如HTTP协议,通信双方数据交互完成之后,通常按照双方的约定由服务端关闭连接,客户端获得TCP连接关闭请求之后,关闭自身的Socket连接,双方正式断开连接。

在实际的NIO编程过程中,经常存在一种误区:认为只要是对方关闭连接,就会发生IO异常,捕获IO异常之后再关闭连接即可。实际上,连接的合法关闭不会发生IO异常,它是一种正常场景,如果遗漏了该场景的判断和处理就会导致连接句柄泄漏。

下面我们一起模拟故障,看Netty是如何处理的。测试场景设计如下:改造下Netty客户端,双发链路建立成功之后,等待120S,客户端正常关闭链路。看服务端是否能够感知并释放句柄资源。

首先启动Netty客户端和服务端,双方TCP链路连接正常:

图2-13 TCP连接状态正常

120S之后,客户端关闭连接,进程退出,为了能够看到整个处理过程,我们在服务端的Reactor线程处设置断点,先不做处理,此时链路状态如下:

图2-14 TCP连接句柄等待释放

从上图可以看出,此时服务端并没有关闭Socket连接,链路处于CLOSE_WAIT状态,放开代码让服务端执行完,结果如下:

图2-15 TCP连接句柄正常释放

下面我们一起看下服务端是如何判断出客户端关闭连接的,当连接被对方合法关闭后,被关闭的SocketChannel会处于就绪状态,SocketChannel的read操作返回值为-1,说明连接已经被关闭,代码如下:

图2-16 需要对读取的字节数进行判断

如果SocketChannel被设置为非阻塞,则它的read操作可能返回三个值:

1) 大于0,表示读取到了字节数;

2) 等于0,没有读取到消息,可能TCP处于Keep-Alive状态,接收到的是TCP握手消息;

3) -1,连接已经被对方合法关闭。

通过调试,我们发现,NIO类库的返回值确实为-1:

图2-17 链路正常关闭,返回值为-1

得知连接关闭之后,Netty将关闭操作位设置为true,关闭句柄,代码如下:

图2-18 连接正常关闭,释放资源

2.1.4. 故障定制

在大多数场景下,当底层网络发生故障的时候,应该由底层的NIO框架负责释放资源,处理异常等。上层的业务应用不需要关心底层的处理细节。但是,在一些特殊的场景下,用户可能需要感知这些异常,并针对这些异常进行定制处理,例如:

1) 客户端的断连重连机制;

2) 消息的缓存重发;

3) 接口日志中详细记录故障细节;

4) 运维相关功能,例如告警、触发邮件/短信等

Netty的处理策略是发生IO异常,底层的资源由它负责释放,同时将异常堆栈信息以事件的形式通知给上层用户,由用户对异常进行定制。这种处理机制既保证了异常处理的安全性,也向上层提供了灵活的定制能力。

具体接口定义以及默认实现如下:

图2-19 故障定制接口

用户可以覆盖该接口,进行个性化的异常定制。例如发起重连等。

2.2. 链路的有效性检测

当网络发生单通、连接被防火墙Hang住、长时间GC或者通信线程发生非预期异常时,会导致链路不可用且不易被及时发现。特别是异常发生在凌晨业务低谷期间,当早晨业务高峰期到来时,由于链路不可用会导致瞬间的大批量业务失败或者超时,这将对系统的可靠性产生重大的威胁。

从技术层面看,要解决链路的可靠性问题,必须周期性的对链路进行有效性检测。目前最流行和通用的做法就是心跳检测。

心跳检测机制分为三个层面:

1) TCP层面的心跳检测,即TCP的Keep-Alive机制,它的作用域是整个TCP协议栈;

2) 协议层的心跳检测,主要存在于长连接协议中。例如SMPP协议;

3) 应用层的心跳检测,它主要由各业务产品通过约定方式定时给对方发送心跳消息实现。

心跳检测的目的就是确认当前链路可用,对方活着并且能够正常接收和发送消息。

做为高可靠的NIO框架,Netty也提供了心跳检测机制,下面我们一起熟悉下心跳的检测原理。

图2-20 心跳检测机制

不同的协议,心跳检测机制也存在差异,归纳起来主要分为两类:

1) Ping-Pong型心跳:由通信一方定时发送Ping消息,对方接收到Ping消息之后,立即返回Pong应答消息给对方,属于请求-响应型心跳;

2) Ping-Ping型心跳:不区分心跳请求和应答,由通信双方按照约定定时向对方发送心跳Ping消息,它属于双向心跳。

心跳检测策略如下:

1) 连续N次心跳检测都没有收到对方的Pong应答消息或者Ping请求消息,则认为链路已经发生逻辑失效,这被称作心跳超时;

2) 读取和发送心跳消息的时候如何直接发生了IO异常,说明链路已经失效,这被称为心跳失败。

无论发生心跳超时还是心跳失败,都需要关闭链路,由客户端发起重连操作,保证链路能够恢复正常。

Netty的心跳检测实际上是利用了链路空闲检测机制实现的,相关代码如下:

图2-21 心跳检测的代码包路径

Netty提供的空闲检测机制分为三种:

1) 读空闲,链路持续时间t没有读取到任何消息;

2) 写空闲,链路持续时间t没有发送任何消息;

3) 读写空闲,链路持续时间t没有接收或者发送任何消息。

Netty的默认读写空闲机制是发生超时异常,关闭连接,但是,我们可以定制它的超时实现机制,以便支持不同的用户场景。

WriteTimeoutHandler的超时接口如下:

图2-22 写超时

ReadTimeoutHandler的超时接口如下:

图2-23 读超时

读写空闲的接口如下:

图2-24 读写空闲

利用Netty提供的链路空闲检测机制,可以非常灵活的实现协议层的心跳检测。在《Netty权威指南》中的私有协议栈设计和开发章节,我利用Netty提供的自定义Task接口实现了另一种心跳检测机制,感兴趣的朋友可以参阅该书。

2.3. Reactor线程的保护

Reactor线程是IO操作的核心,NIO框架的发动机,一旦出现故障,将会导致挂载在其上面的多路用复用器和多个链路无法正常工作。因此它的可靠性要求非常高。

笔者就曾经遇到过因为异常处理不当导致Reactor线程跑飞,大量业务请求处理失败的故障。下面我们一起看下Netty是如何有效提升Reactor线程的可靠性的。

2.3.1. 异常处理要当心

尽管Reactor线程主要处理IO操作,发生的异常通常是IO异常,但是,实际上在一些特殊场景下会发生非IO异常,如果仅仅捕获IO异常可能就会导致Reactor线程跑飞。为了防止发生这种意外,在循环体内一定要捕获Throwable,而不是IO异常或者Exception。

Netty的相关代码如下:

图2-25 Reactor线程异常保护

捕获Throwable之后,即便发生了意外未知对异常,线程也不会跑飞,它休眠1S,防止死循环导致的异常绕接,然后继续恢复执行。这样处理的核心理念就是:

1) 某个消息的异常不应该导致整条链路不可用;

2) 某条链路不可用不应该导致其它链路不可用;

3) 某个进程不可用不应该导致其它集群节点不可用。

2.3.2. 死循环保护

通常情况下,死循环是可检测、可预防但是无法完全避免的。Reactor线程通常处理的都是IO相关的操作,因此我们重点关注IO层面的死循环。

JDK NIO类库最著名的就是 epoll bug了,它会导致Selector空轮询,IO线程CPU 100%,严重影响系统的安全性和可靠性。

SUN在JKD1.6 update18版本声称解决了该BUG,但是根据业界的测试和大家的反馈,直到JDK1.7的早期版本,该BUG依然存在,并没有完全被修复。发生该BUG的主机资源占用图如下:

图2-26 epoll bug CPU空轮询

SUN在解决该BUG的问题上不给力,只能从NIO框架层面进行问题规避,下面我们看下Netty是如何解决该问题的。

Netty的解决策略:

1) 根据该BUG的特征,首先侦测该BUG是否发生;

2) 将问题Selector上注册的Channel转移到新建的Selector上;

3) 老的问题Selector关闭,使用新建的Selector替换。

下面具体看下代码,首先检测是否发生了该BUG:

图2-27 epoll bug 检测

一旦检测发生该BUG,则重建Selector,代码如下:

图2-28 重建Selector

重建完成之后,替换老的Selector,代码如下:

图2-29 替换Selector

大量生产系统的运行表明,Netty的规避策略可以解决epoll bug 导致的IO线程CPU死循环问题。

2.4. 优雅退出

Java的优雅停机通常通过注册JDK的ShutdownHook来实现,当系统接收到退出指令后,首先标记系统处于退出状态,不再接收新的消息,然后将积压的消息处理完,最后调用资源回收接口将资源销毁,最后各线程退出执行。

通常优雅退出有个时间限制,例如30S,如果到达执行时间仍然没有完成退出前的操作,则由监控脚本直接kill -9 pid,强制退出。

Netty的优雅退出功能随着版本的优化和演进也在不断的增强,下面我们一起看下Netty5的优雅退出。

首先看下Reactor线程和线程组,它们提供了优雅退出接口。EventExecutorGroup的接口定义如下:

图2-30 EventExecutorGroup优雅退出

NioEventLoop的资源释放接口实现:

图2-31 NioEventLoop资源释放

ChannelPipeline的关闭接口:

图2-32 ChannelPipeline关闭接口

目前Netty向用户提供的主要接口和类库都提供了资源销毁和优雅退出的接口,用户的自定义实现类可以继承这些接口,完成用户资源的释放和优雅退出。

2.5. 内存保护

2.5.1. 缓冲区的内存泄漏保护

为了提升内存的利用率,Netty提供了内存池和对象池。但是,基于缓存池实现以后需要对内存的申请和释放进行严格的管理,否则很容易导致内存泄漏。

如果不采用内存池技术实现,每次对象都是以方法的局部变量形式被创建,使用完成之后,只要不再继续引用它,JVM会自动释放。但是,一旦引入内存池机制,对象的生命周期将由内存池负责管理,这通常是个全局引用,如果不显式释放JVM是不会回收这部分内存的。

对于Netty的用户而言,使用者的技术水平差异很大,一些对JVM内存模型和内存泄漏机制不了解的用户,可能只记得申请内存,忘记主动释放内存,特别是JAVA程序员。

为了防止因为用户遗漏导致内存泄漏,Netty在Pipe line的尾Handler中自动对内存进行释放,相关代码如下:

图2-33 TailHandler的内存回收操作

对于内存池,实际就是将缓冲区重新放到内存池中循环使用,代码如下:

图2-34 PooledByteBuf的内存回收操作

2.5.2. 缓冲区内存溢出保护

做过协议栈的读者都知道,当我们对消息进行解码的时候,需要创建缓冲区。缓冲区的创建方式通常有两种:

1) 容量预分配,在实际读写过程中如果不够再扩展;

2) 根据协议消息长度创建缓冲区。

在实际的商用环境中,如果遇到畸形码流攻击、协议消息编码异常、消息丢包等问题时,可能会解析到一个超长的长度字段。笔者曾经遇到过类似问题,报文长度字段值竟然是2G多,由于代码的一个分支没有对长度上限做有效保护,结果导致内存溢出。系统重启后几秒内再次内存溢出,幸好及时定位出问题根因,险些酿成严重的事故。

Netty提供了编解码框架,因此对于解码缓冲区的上限保护就显得非常重要。下面,我们看下Netty是如何对缓冲区进行上限保护的:

首先,在内存分配的时候指定缓冲区长度上限:

图2-35 缓冲区分配器可以指定缓冲区最大长度

其次,在对缓冲区进行写入操作的时候,如果缓冲区容量不足需要扩展,首先对最大容量进行判断,如果扩展后的容量超过上限,则拒绝扩展:

图2-35 缓冲区扩展上限保护

最后,在解码的时候,对消息长度进行判断,如果超过最大容量上限,则抛出解码异常,拒绝分配内存:

图2-36 超出容量上限的半包解码,失败

图2-37 抛出TooLongFrameException异常

2.6. 流量整形

大多数的商用系统都有多个网元或者部件组成,例如参与短信互动,会涉及到手机、基站、短信中心、短信网关、SP/CP等网元。不同网元或者部件的处理性能不同。为了防止因为浪涌业务或者下游网元性能低导致下游网元被压垮,有时候需要系统提供流量整形功能。

下面我们一起看下流量整形(traffic shaping)的定义:流量整形(Traffic Shaping)是一种主动调整流量输出速率的措施。一个典型应用是基于下游网络结点的TP指标来控制本地流量的输出。流量整形与流量监管的主要区别在于,流量整形对流量监管中需要丢弃的报文进行缓存——通常是将它们放入缓冲区或队列内,也称流量整形(Traffic Shaping,简称TS)。当令牌桶有足够的令牌时,再均匀的向外发送这些被缓存的报文。流量整形与流量监管的另一区别是,整形可能会增加延迟,而监管几乎不引入额外的延迟。

流量整形的原理示意图如下:

图2-38 流量整形原理图

作为高性能的NIO框架,Netty的流量整形有两个作用:

1) 防止由于上下游网元性能不均衡导致下游网元被压垮,业务流程中断;

2) 防止由于通信模块接收消息过快,后端业务线程处理不及时导致的“撑死”问题。

下面我们就具体学习下Netty的流量整形功能。

2.6.1. 全局流量整形

全局流量整形的作用范围是进程级的,无论你创建了多少个Channel,它的作用域针对所有的Channel。

用户可以通过参数设置:报文的接收速率、报文的发送速率、整形周期。相关的接口如下所示:

图2-39 全局流量整形参数设置

Netty流量整形的原理是:对每次读取到的ByteBuf可写字节数进行计算,获取当前的报文流量,然后与流量整形阈值对比。如果已经达到或者超过了阈值。则计算等待时间delay,将当前的ByteBuf放到定时任务Task中缓存,由定时任务线程池在延迟delay之后继续处理该ByteBuf。相关代码如下:

图2-40 动态计算当前流量

如果达到整形阈值,则对新接收的ByteBuf进行缓存,放入线程池的消息队列中,稍后处理,代码如下:

图2-41 缓存当前的ByteBuf

定时任务的延时时间根据检测周期T和流量整形阈值计算得来,代码如下:

图2-42 计算缓存等待周期

需要指出的是,流量整形的阈值limit越大,流量整形的精度越高,流量整形功能是可靠性的一种保障,它无法做到100%的精确。这个跟后端的编解码以及缓冲区的处理策略相关,此处不再赘述。感兴趣的朋友可以思考下,Netty为什么不做到 100%的精确。

流量整形与流控的最大区别在于流控会拒绝消息,流量整形不拒绝和丢弃消息,无论接收量多大,它总能以近似恒定的速度下发消息,跟变压器的原理和功能类似。

2.6.2. 单条链路流量整形

除了全局流量整形,Netty也支持但链路的流量整形,相关的接口定义如下:

图2-43 单链路流量整形

单链路流量整形与全局流量整形的最大区别就是它以单个链路为作用域,可以对不同的链路设置不同的整形策略。

它的实现原理与全局流量整形类似,我们不再赘述。值得说明的是,Netty支持用户自定义流量整形策略,通过继承AbstractTrafficShapingHandler的doAccounting方法可以定制整形策略。相关接口定义如下:

图2-44 定制流量整形策略

3. 总结

尽管Netty在架构可靠性上面已经做了很多精细化的设计,以及基于防御式编程对系统进行了大量可靠性保护。但是,系统的可靠性是个持续投入和改进的过程,不可能在一个版本中一蹴而就,可靠性工作任重而道远。

从业务的角度看,不同的行业、应用场景对可靠性的要求也是不同的,例如电信行业的可靠性要求是5个9,对于铁路等特殊行业,可靠性要求更高,达到6个9。对于企业的一些边缘IT系统,可靠性要求会低些。

可靠性是一种投资,对于企业而言,追求极端可靠性对研发成本是个沉重的包袱,但是相反,如果不重视系统的可靠性,一旦不幸遭遇网上事故,损失往往也是惊人的。

对于架构师和设计师,如何权衡架构的可靠性和其它特性的关系,是一个很大的挑战。通过研究和学习Netty的可靠性设计,也许能够给大家带来一些启示。

4. Netty学习推荐书籍

目前市面上介绍netty的文章很多,如果读者希望系统性的学习Netty,推荐两本书:

1) 《Netty in Action》

2) 《Netty权威指南》

5.作者简介

李林锋,2007年毕业于东北大学,2008年进入华为公司从事高性能通信软件的设计和开发工作,有6年NIO设计和开发经验,精通Netty、Mina等NIO框架。Netty中国社区创始人,《Netty权威指南》作者。

原文链接:http://www.infoq.com/cn/articles/netty-reliability

Posted in 搜索与分布式 | Leave a comment

分布式存储系统的雪崩效应

一 分布式存储系统背景

副本是分布式存储系统中的常见概念:将一定大小的数据按照一定的冗余策略存储,以保障系统在局部故障情况下的可用性。

副本间的冗余复制方式有多种,比较常用有两类:

  • Pipeline:像个管道,a->b->c,通过管道的方式进行数据的复制。该方式吞吐较高,但有慢节点问题,某一节点出现拥塞,整个过程都会受影响
  • 分发:client -> a  client ->b client ->c。系统整体吞吐较低,但无慢节点问题

对于冗余副本数目,本文选择常见的三副本方案。

二 雪崩效应的产生

在一段时间内数目较多的宕机事件有较大可能性诱发系统的大规模副本补全策略。目前的分布式存储系统的两个特点导致这个大规模副本补全策略容易让系统产生雪崩效应:

a. 集群整体的free空间较小:通常整体<=30%, 局部机器小于<=20% 甚至10%

   b. 应用混布:不同的应用部署在同一台物理/虚拟机器上以最大化利用硬件资源

今年火起来的各种网盘、云盘类服务就是a的典型情况。在各大公司拼个人存储容量到1T的背后,其实也在拼运营成本、运维成本。现有的云存储大多只增不减、或者根据数据冷热程度做数据分级(类似Facebook的数据分级项目)。云存储总量大,但增量相对小,为了减少存储资源和带宽资源浪费,新创建的文件若原有的存储数据中已有相同的md5或者sha1签名则当做已有文件做内部链接,不再进行新文件的创建。但即使这样,整体的数据量还是很大。

目前云存储相关业务未有明显的收入来源,每年却有数万每台的服务器成本,为运营成本的考虑,后端分布式存储系统的空闲率很低。而瞬间的批量宕机会带来大量的副本修复,大量的副本修复很有可能继而打满原本就接近存储quota的其他存活机器,继而让该机器处于宕机或者只读状态。如此继续,整个集群可能雪崩,系统残废。

三 预防雪崩

本节主要讨论如何在系统内部的逻辑处理上防止系统整体雪崩的发生。预防的重要性大于事故之后的处理,预测集群状态、提前进行优化也成为预防雪崩的一个方向。

下面选取曾经发生过的几个实际场景与大家分享。

1. 跨机架副本选择算法和机器资源、用户逻辑隔离

现场还原:

某天运维同学发现某集群几十台机器瞬间失联,负责触发修复副本的主控节点开始进行疯狂的副本修复。大量用户开始反馈集群变慢,读写夯住。

现场应对:

优先解决——副本修复量过大造成的集群整体受影响。

a. 处理的工程师当机立断,gdb到进程更改修复副本的条件为副本<2,而非原本的3(replicas_num),让主控节点这个时候仅修复副本数小于2个的文件,即保证未丢失的文件有至少一个冗余副本,防止只有一个副本的数据因可能再次发生的挂机造成文件丢失。

b. 紧急解决这批机器失联问题,发现是交换机问题,a.b.c.d ip网段的c网段机器批量故障。催促网络组尽快修复。

c. 副本修复到>=2之后,Gdb更改检测副本不足周期,将几十秒的检测时间推迟到1天。等待网络组解决交换机问题。

d. 网络恢复,原有的机器重新加入集群。大量2副本文件重新变为3副本,部分3副本全丢失文件找回。

e. 恢复主控节点到正常参数设置状态,系统开始正常修复。

改进措施:

在改进措施前,先分析下这次事件暴露的系统不足:

1) Master参数不支持热修正,Gdb线上进程风险过大。

2) 一定数量但局域性的机器故障影响了整体集群(几十台相对一个大集群仍属于局域性故障)。如上所述,月千分之几的故障率总有机会让你的存储系统经历一次交换机故障带来的集群影响。

案例分析后的改进措施出炉:

1)  Master支持热修正功能排期提前,尽早支持核心参数的热修改。

热修改在上线后的效果可观,后续规避过数次线上问题。

2) 在选择数据副本存储宿主机器的pickup算法中加入跨交换机(机架位)策略,强制——或者尽量保证——副本选择时跨机架位。这种算法底下的副本,至少有1个副本与其他两个副本处于不同的交换机下(IP a.b.c.d的c段)。该措施同时作用于新的存储数据副本选择和副本缺失后的副本补全策略,能在副本宿主选择上保证系统不会因为交换机的宕机而出现数据丢失,进而避免一直处于副本补全队列/列表的大量的丢失副本节点加重主控节点负载。

3) 机器按region划分隔离功能提上日程;用户存储位置按照region进行逻辑划分功能提上日程;Pickup算法加入跨region提上日程。

a) 机器按照物理位置划分region、用户按照region进行逻辑存储位置划分,能让集群在局部故障的情况下仅影响被逻辑划分进使用这部分机器的用户。

这样一来,最坏情况无非是这个region不可用,导致拥有这个region读写权限的用户受影响。Pickup算法跨region的设计进一步保证被划分region的用户不会因为一个region不可用而出现数据丢失,因为其他副本存到其他region上了。于是,核心交换机故障导致一个region数百台机器的宕机也不会对集群造成范围过大的影响了。

b) 增加region可信度概念,将机器的稳定性因素加入到副本冗余算法中。

当集群规模达到一定量后,会出现机器稳定性不同的问题(一般来说,同一批上线的机器稳定性一致)。通过标记region的稳定性,能强制在选择数据副本的时候将至少一个副本至于稳定副本中,减少全部副本丢失的概率。

c) Region划分需要综合考虑用户操作响应时间SLA、物理机器稳定情况、地理位置等信息。

合理的region划分对提升系统稳定性、提升操作相应时间、预防系统崩溃都有益处。精巧的划分规则会带来整体的稳定性提升,但也增加了系统的复杂度。这块如何取舍,留给读者朋友深入思考了。

2. 让集群流控起来

流控方面有个通用且符合分布式存储系统特点的原则:任何操作都不应占用过多的处理时间。这里的“任何操作”包含了在系统出现流量激增、局部达到一定数量的机器宕机时进行的操作。只有平滑且成功的处理这些操作,才能保证系统不因为异常而出现整体受影响,甚至雪崩。

现场还原:

1) 场景1 某天运维同学发现,集群写操作在某段时间大增。通过观察某个存储节点,发现不仅是写、而且是随机写!某些产品线的整体吞吐下降了。

2) 场景2 某集群存储大户需要进行业务调整,原有的数据做变更,大量数据需要删除。

运维同学发现,a. 整个集群整体上处于疯狂gc垃圾回收阶段 b. 集群响应速度明显变慢,特别是涉及到meta元信息更新的操作。

3) 场景3 某天运维同学突然发现集群并发量激增,单一用户xyz进行了大量的并发操作,按照原有的用户调研,该用户不应该拥有如此规模的使用场景。

此类集群某些操作预期外的激增还有很多,不再累述。

现场应对:

1) 立刻电联相关用户,了解操作激增原因,不合理的激增需要立刻处理。

我们发现过如下不合理的激增:

a. 场景1类:通过Review代码发现,大量的操作进行了随机读写更改。建议用户将随机读写转换为读取后更改+写新文件+删除旧文件,转换随机读写为顺序读写。

b. 场景3类:某产品线在线上进行了性能测试。运维同学立刻通知该产品线停止了相关操作。所有公有集群再次发通过邮件强调,不可用于性能测试。如有需要,联系相关人员在独占集群进行性能场景测试。

2) 推动设计和实现集群各个环节的流控机制功能并上线。

改进措施:

1) 用户操作流控

a. 对用户操作进行流控限制

可通过系统内部设计实现,也可通过外部的网络限流等方式实现,对单用户做一定的流控限制,防止单个用户占用过多整个集群的资源。

b. 存储节点操作流控

可按照对集群的资源消耗高低分为High – Medium – Low三层,每层实现类似于抢token的设计,每层token数目在集群实践后调整为比较适合的值。这样能防止某类操作过多消耗集群负载。若某类操作过多消耗负载,其他操作类的请求有较大delay可能,继而引发timeout后的重试、小范围的崩溃,有一定几率蔓延到整个集群并产生整体崩溃。

c. 垃圾回收gc单独做流控处理。删除操作在分布式存储系统里面常用设计是:接收到用户删除操作时,标记删除内容的meta信息,直接回返,后续进行策略控制,限流的删除,防止大量的gc操作消耗过多单机存储节点的磁盘处理能力。具体的限流策略和token值设置需要根据集群特点进行实践并得出较优设置。

2) 流控黑名单

用户因为对线上做测试类的场景可以通过人为制度约束,但无法避免线上用户bug导致效果等同于线上测试规模的场景。这类的场景一般在短时间内操作数严重超过限流上限。

对此类场景可进行流控黑名单设置,当某用户短时间内(e.g. 1小时)严重超过设置的上限时,将该用户加入黑名单,暂时阻塞操作。外围的监控会通知运维组同学紧急处理。

3) 存储节点并发修复、创建副本流控

大量的数据副本修复操作或者副本创建操作如果不加以速度限制,将占用存储节点的带宽和CPU、内存等资源,影响正常的读写服务,出现大量的延迟。而大量的延迟可能引发重试,加重集群的繁忙程度。

同一个数据宿主进程需要限制并发副本修复、副本创建的个数,这样对入口带宽的占用不会过大,进程也不会因为过量进行这类操作而增加大量其他操作的延迟时间。这对于采用分发的副本复制协议的系统尤其重要。分发协议一般都有慢节点检查机制,副本流控不会进一步加重系统延迟而增大成为慢节点的可能。如果慢节点可能性增大,新创建的文件可能在创建时就因为慢节点检查机制而缺少副本,这会让集群状况更加恶化。

3. 提前预测、提前行动

1) 预测磁盘故障,容错单磁盘错误。

场景复现:

某厂商的SSD盘某批次存在问题,集群上线运行一段时间后,局部集中出现数量较多的坏盘,但并非所有的盘都损坏。当时并未有单磁盘容错机制,一块磁盘坏掉,整个机器就被置成不可用状态,这样导致拥有这批坏盘的机器都不可用,集群在一段时间内都处于副本修复状态,吞吐受到较大影响。

改进措施:

a) 对硬盘进行健康性预测,自动迁移大概率即将成为坏盘的数据副本

近年来,对磁盘健康状态进行提前预测的技术越来越成熟,技术上已可以预判磁盘健康程度并在磁盘拥有大概率坏掉前,自动迁移数据到其他磁盘,减少磁盘坏掉对系统稳定性的影响。

b) 对单硬盘错误进行容错处理

存储节点支持对坏盘的异常处理。单盘挂掉时,自动迁移/修复单盘的原有数据到其他盘,而不是进程整体宕掉,因为一旦整体宕掉,其他盘的数据也会被分布式存储系统当做缺失副本,存储资源紧张的集群经历一次这样的宕机事件会造成长时间的副本修复过程。在现有的分布式存储系统中, 也有类似淘宝TFS那样,每个磁盘启动一个进程进行管理,整机挂载多少个盘就启动多少个进程。

2) 根据现有存储分布,预测均衡性发展,提前进行负载均衡操作。

这类的策略设计越来越常见。由于分布式存储集群挂机后的修复策略使得集群某些机器总有几率成为热点机器,我们可以对此类的机器进行热点预测,提前迁移部分数据到相对负载低的机器。

负载均衡策略和副本选择策略一样,需要取舍复杂度和优化程度问题。复杂的均衡策略带来好的集群负载,但也因此引入高复杂度、高bug率问题。如何取舍,仍旧是个困扰分布式存储系统设计者的难题。

四 安全模式

安全模式是项目实践过程中产生的防分布式存储系统雪崩大杀器,因此我特别将其单独列为一节介绍。其基本思路是在一定时间内宕机数目超过预期上限则让集群进入安全模式,按照策略配置、情况严重程度,停止修复副本、停止读写,直到停止一切操作(一般策略)。

在没有机器region概念的系统中,安全模式可以起到很好的保护作用。我过去参与的一个项目经历的某次大规模宕机,由于没有安全模式,系统进行正常的处理副本修复,生生将原本健康的存储节点也打到残废,进而雪崩,整个集群都陷入疯狂副本修复状态。这种状态之后的集群修复过程会因为已发生的副本修复导致的元信息/实际数据的更改而变的困难重重。 该事件最后结局是数据从冷备数据中恢复了一份,丢失了冷备到故障发生时间的数据。

当然,安全模式并非完美无缺。“一段时间”、“上限”该如何设置、什么时候停副本修复、什么时候停读、什么时候停写、是自己恢复还是人工干预恢复到正常状态、安全模式力度是否要到region级别,这些问题都需要安全模式考虑,而此类的设计一般都和集群设计的目标用户息息相关。举例,如果是低延迟且业务敏感用户,可能会选择小规模故障不能影响读写,而高延迟、高吞吐集群就可以接受停读写。

五 思考

由于分布式存储系统的复杂性和篇幅所限,本文仅选择有限个典型场景进行了分析和讨论, 真实的分布式存储系统远比这数个案例复杂的多、细节的多。如何平衡集群异常自动化处理和引入的复杂度,如何较好的实现流控和避免影响低延迟用户的响应时间,如何引导集群进行负载均衡和避免因负载均衡带来的过量集群资源开销,这类问题在真实的分布式存储系统设计中层出不穷。如果设计者是你,你会如何取舍呢?


感谢丁雪丰对本文的审校。

原文地址:分布式存储系统的雪崩效应

Posted in 搜索与分布式 | Leave a comment

Apache Kafka:下一代分布式消息系统

本文kafka的介绍和实现原理是基于0.7.2版本或以下版本的,最新版本的kafka在实在上做了比较大的调整,以至于与0.7的版本不兼容,但其官方上还是提供了个程序方便其用户把现有基于0.7老版本的数据导入到新版本。

简介

Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发,之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的,分区的和可复制的提交日志服务。

Apache Kafka与传统消息系统相比,有以下不同:

  • 它被设计为一个分布式系统,易于向外扩展;
  • 它同时为发布和订阅提供高吞吐量;
  • 它支持多订阅者,当失败时能自动平衡消费者;
  • 它将消息持久化到磁盘,因此可用于批量消费,例如ETL,以及实时应用程序。

本文我将重点介绍Apache Kafka的架构、特性和特点,帮助我们理解Kafka为何比传统消息服务更好。

我将比较Kafak和传统消息服务RabbitMQ、Apache ActiveMQ的特点,讨论一些Kafka优于传统消息服务的场景。在最后一节,我们将探讨一个进行中的示例应用,展示Kafka作为消息服务器的用途。这个示例应用的完整源代码在GitHub。关于它的详细讨论在本文的最后一节。

架构

首先,我介绍一下Kafka的基本概念。它的架构包括以下组件:

  • 话题(Topic)是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名。
  • 生产者(Producer)是能够发布消息到话题的任何对象。
  • 已发布的消息保存在一组服务器中,它们被称为代理(Broker)或Kafka集群
  • 消费者可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息。

图1:Kafka生产者、消费者和代理环境

生产者可以选择自己喜欢的序列化方法对消息内容编码。为了提高效率,生产者可以在一个发布请求中发送一组消息。下面的代码演示了如何创建生产者并发送消息。

生产者示例代码:

producer = new Producer(…); 
message = new Message(“test message str”.getBytes()); 
set = new MessageSet(message); 
producer.send(“topic1”, set);

为了订阅话题,消费者首先为话题创建一个或多个消息流。发布到该话题的消息将被均衡地分发到这些流。每个消息流为不断产生的消息提供了迭代接口。然后消费者迭代流中的每一条消息,处理消息的有效负载。与传统迭代器不同,消息流迭代器永不停止。如果当前没有消息,迭代器将阻塞,直到有新的消息发布到该话题。Kafka同时支持点到点分发模型(Point-to-point delivery model),即多个消费者共同消费队列中某个消息的单个副本,以及发布-订阅模型(Publish-subscribe model),即多个消费者接收自己的消息副本。下面的代码演示了消费者如何使用消息。

消费者示例代码:

streams[] = Consumer.createMessageStreams(“topic1”, 1) 
for (message : streams[0]) { 
bytes = message.payload(); 
// do something with the bytes 
}

Kafka的整体架构如图2所示。因为Kafka内在就是分布式的,一个Kafka集群通常包括多个代理。为了均衡负载,将话题分成多个分区,每个代理存储一或多个分区。多个生产者和消费者能够同时生产和获取消息。

图2:Kafka架构

Kafka存储

Kafka的存储布局非常简单。话题的每个分区对应一个逻辑日志。物理上,一个日志为相同大小的一组分段文件。每次生产者发布消息到一个分区,代理就将消息追加到最后一个段文件中。当发布的消息数量达到设定值或者经过一定的时间后,段文件真正写入磁盘中。写入完成后,消息公开给消费者。

与传统的消息系统不同,Kafka系统中存储的消息没有明确的消息Id。

消息通过日志中的逻辑偏移量来公开。这样就避免了维护配套密集寻址,用于映射消息ID到实际消息地址的随机存取索引结构的开销。消息ID是增量的,但不连续。要计算下一消息的ID,可以在其逻辑偏移的基础上加上当前消息的长度。

消费者始终从特定分区顺序地获取消息,如果消费者知道特定消息的偏移量,也就说明消费者已经消费了之前的所有消息。消费者向代理发出异步拉请求,准备字节缓冲区用于消费。每个异步拉请求都包含要消费的消息偏移量。Kafka利用sendfile API高效地从代理的日志段文件中分发字节给消费者。注:这个地方写的不是太好懂,消费者自己维护自己的消费状态(已消费消息的偏移量),下次取消息时会从这个偏移量开始顺序的消费消息。

图3:Kafka存储架构

Kafka代理

与其它消息系统不同,Kafka代理是无状态的。这意味着消费者必须维护已消费的状态信息。这些信息由消费者自己维护,代理完全不管。这种设计非常微妙,它本身包含了创新。

  • 从代理删除消息很棘手,因为代理并不知道消费者是否已经使用了该消息。Kafka创新性地解决了这个问题,它将一个简单的基于时间的SLA应用于保留策略。当消息在代理中超过一定时间后,将会被自动删除。注:kafka的broker在配置文件中可以配置最多保存多少小时的数据和分区最大的空间占用,过期的和超量的数据会被broker自动清除掉。
  • 这种创新设计有很大的好处,消费者可以故意倒回到老的偏移量再次消费数据。这违反了队列的常见约定,但被证明是许多消费者的基本特征。注:消息存放在磁盘中,所以其可以保存大量的消息,消息获取依据分区offset值,所以给一个老的偏移量就能够从broker中取下相应偏移量后的消息。这个特征对需要重算的消费者是方便的。

ZooKeeper与Kafka

考虑一下有多个服务器的分布式系统,每台服务器都负责保存数据,在数据上执行操作。这样的潜在例子包括分布式搜索引擎、分布式构建系统或者已知的系统如Apache Hadoop。所有这些分布式系统的一个常见问题是,你如何在任一时间点确定哪些服务器活着并且在工作中。最重要的是,当面对这些分布式计算的难题,例如网络失败、带宽限制、可变延迟连接、安全问题以及任何网络环境,甚至跨多个数据中心时可能发生的错误时,你如何可靠地做这些事。这些正是Apache ZooKeeper所关注的问题,它是一个快速、高可用、容错、分布式的协调服务。你可以使用ZooKeeper构建可靠的、分布式的数据结构,用于群组成员、领导人选举、协同工作流和配置服务,以及广义的分布式数据结构如锁、队列、屏障(Barrier)和锁存器(Latch)。许多知名且成功的项目依赖于ZooKeeper,其中包括HBase、Hadoop 2.0、Solr Cloud、Neo4J、Apache Blur(Incubating)和Accumulo。

ZooKeeper是一个分布式的、分层级的文件系统,能促进客户端间的松耦合,并提供最终一致的,类似于传统文件系统中文件和目录的Znode视图。它提供了基本的操作,例如创建、删除和检查Znode是否存在。它提供了事件驱动模型,客户端能观察特定Znode的变化,例如现有Znode增加了一个新的子节点。ZooKeeper运行多个ZooKeeper服务器,称为Ensemble,以获得高可用性。每个服务器都持有分布式文件系统的内存复本,为客户端的读取请求提供服务。

图4:ZooKeeper Ensemble架构

上图4展示了典型的ZooKeeper ensemble,一台服务器作为Leader,其它作为Follower。当Ensemble启动时,先选出Leader,然后所有Follower复制Leader的状态。所有写请求都通过Leader路由,变更会广播给所有Follower。变更广播被称为原子广播

Kafka中ZooKeeper的用途:正如ZooKeeper用于分布式系统的协调和促进,Kafka使用ZooKeeper也是基于相同的原因。ZooKeeper用于管理、协调Kafka代理。每个Kafka代理都通过ZooKeeper协调其它Kafka代理。当Kafka系统中新增了代理或者某个代理故障失效时,ZooKeeper服务将通知生产者和消费者。生产者和消费者据此开始与其它代理协调工作。Kafka整体系统架构如图5所示。注:broker和生产者、消费者各自都是集群,集群中的各个实例他们之间是对等的,集群扩充节点很方便。

图5:Kafka分布式系统的总体架构

Apache Kafka对比其它消息服务

让我们了解一下使用Apache Kafka的两个项目,以对比其它消息服务。这两个项目分别是LinkedIn和我的项目:

LinkedIn的研究

LinkedIn团队做了个实验研究,对比Kafka与Apache ActiveMQ V5.4和RabbitMQ V2.4的性能。他们使用ActiveMQ默认的消息持久化库Kahadb。LinkedIn在两台Linux机器上运行他们的实验,每台机器的配置为8核2GHz、16GB内存,6个磁盘使用RAID10。两台机器通过1GB网络连接。一台机器作为代理,另一台作为生产者或者消费者。

生产者测试

LinkedIn团队在所有系统中配置代理,异步将消息刷入其持久化库。对每个系统,运行一个生产者,总共发布1000万条消息,每条消息200字节。Kafka生产者以1和50批量方式发送消息。ActiveMQ和RabbitMQ似乎没有简单的办法来批量发送消息,LinkedIn假定它的批量值为1。结果如下面的图6所示:

图6:LinkedIn的生产者性能实验结果

Kafka性能要好很多的主要原因包括:

  • Kafka不等待代理的确认,以代理能处理的最快速度发送消息。
  • Kafka有更高效的存储格式。平均而言,Kafka每条消息有9字节的开销,而ActiveMQ有144字节。其原因是JMS所需的沉重消息头,以及维护各种索引结构的开销。LinkedIn注意到ActiveMQ一个最忙的线程大部分时间都在存取B-Tree以维护消息元数据和状态。
  • 注:kafka使用sendfile、多条消息可打包压缩和传递,磁盘中顺序直接存储不需要维护复杂的存储结构。

消费者测试

为了做消费者测试,LinkedIn使用一个消费者获取总共1000万条消息。LinkedIn让所有系统每次拉请求都预获取大约相同数量的数据,最多1000条消息或者200KB。对ActiveMQ和RabbitMQ,LinkedIn设置消费者确认模型为自动。结果如图7所示。

图7:LinkedIn的消费者性能实验结果

Kafka性能要好很多的主要原因包括:

  • Kafka有更高效的存储格式;在Kafka中,从代理传输到消费者的字节更少。注:消息在生产者处打包压缩成消息集,发送到代理上,代理不加修改直接顺序存储收到的消息集合,当消费者消费消息时,通过sendfile系统调用把消息集发给消费者,消费者自己根据消息块中的标识解压消息集得到一条条消息。所以传输层传递的消息字节更少。
  • ActiveMQ和RabbitMQ两个容器中的代理必须维护每个消息的传输状态。注:其实就是消息是否消费成功,代理是否可以在代理上清除消息的ack,也就是需要维护消费状态  LinkedIn团队注意到其中一个ActiveMQ线程在测试过程中,一直在将KahaDB页写入磁盘。与此相反,Kafka代理没有磁盘写入动作。最后,Kafka通过使用sendfile API降低了传输开销。

目前,我正在工作的一个项目提供实时服务,从消息中快速并准确地提取场外交易市场(OTC)定价内容。这是一个非常重要的项目,处理近25种资产类别的财务信息,包括债券、贷款和ABS(资产担保证券)。项目的原始信息来源涵盖了欧洲、北美、加拿大和拉丁美洲的主要金融市场领域。下面是这个项目的一些统计,说明了解决方案中包括高效的分布式消息服务是多么重要:

  • 每天处理的消息数量超过1,300,000
  • 每天解析的OTC价格数量超过12,000,000
  • 支持超过25种资产类别;
  • 每天解析的独立票据超过70,000

消息包含PDF、Word文档、Excel及其它格式。OTC定价也可能要从附件中提取。

由于传统消息服务器的性能限制,当处理大附件时,消息队列变得非常大,我们的项目面临严重的问题,JMSqueue一天需要启动2-3次。重启JMS队列可能丢失队列中的全部消息。项目需要一个框架,不论解析器(消费者)的行为如何,都能够保住消息。Kafka的特性非常适用于我们项目的需求。

当前项目具备的特性:

  1. 使用Fetchmail获取远程邮件消息,然后由Procmail过滤并处理,例如单独分发基于附件的消息。
  2. 每条消息从单独的文件获取,该文件被处理(读取和删除)为一条消息插入到消息服务器中。
  3. 消息内容从消息服务队列中获取,用于解析和提取信息。

示例应用

这个示例应用是基于我在项目中使用的原始应用修改后的版本。我已经删除日志的使用和多线程特性,使示例应用的工件尽量简单。示例应用的目的是展示如何使用Kafka生产者和消费者的API。应用包括一个生产者示例(简单的生产者代码,演示Kafka生产者API用法并发布特定话题的消息),消费者示例(简单的消费者代码,用于演示Kafka消费者API的用法)以及消息内容生成API(在特定路径下生成消息内容到文件的API)。下图展示了各组件以及它们与系统中其它组件间的关系。

图8:示例应用组件架构

示例应用的结构与Kafka源代码中的例子程序相似。应用的源代码包含Java源程序文件夹‘src’和’config’文件夹,后者包括几个配置文件和一些Shell脚本,用于执行示例应用。要运行示例应用,请参照ReadMe.md文件或GitHub网站Wiki页面的说明。

程序构建可以使用Apache Maven,定制也很容易。如果有人想修改或定制示例应用的代码,有几个Kafka构建脚本已经过修改,可用于重新构建示例应用代码。关于如何定制示例应用的详细描述已经放在项目GitHub的Wiki页面

现在,让我们看看示例应用的核心工件。

Kafka生产者代码示例

/** 
 * Instantiates a new Kafka producer. 
 * 
 * @param topic the topic 
 * @param directoryPath the directory path 
 */ 
public KafkaMailProducer(String topic, String directoryPath) { 
       props.put("serializer.class", "kafka.serializer.StringEncoder"); 
       props.put("metadata.broker.list", "localhost:9092"); 
       producer = new kafka.javaapi.producer.Producer<Integer, String>(new ProducerConfig(props)); 
       this.topic = topic; 
       this.directoryPath = directoryPath; 
} 

public void run() { 
      Path dir = Paths.get(directoryPath); 
      try { 
           new WatchDir(dir).start(); 
           new ReadDir(dir).start(); 
      } catch (IOException e) { 
           e.printStackTrace(); 
      } 
}

上面的代码片断展示了Kafka生产者API的基本用法,例如设置生产者的属性,包括发布哪个话题的消息,可以使用哪个序列化类以及代理的相关信息。这个类的基本功能是从邮件目录读取邮件消息文件,然后作为消息发布到Kafka代理。目录通过java.nio.WatchService类监视,一旦新的邮件消息Dump到该目录,就会被立即读取并作为消息发布到Kafka代理。

Kafka消费者代码示例

public KafkaMailConsumer(String topic) { 
       consumer = 
Kafka.consumer.Consumer.createJavaConsumerConnector(createConsumerConfig()); 
       this.topic = topic; 
} 

/** 
 * Creates the consumer config. 
 * 
 * @return the consumer config 
 */ 
private static ConsumerConfig createConsumerConfig() { 
      Properties props = new Properties(); 
      props.put("zookeeper.connect", KafkaMailProperties.zkConnect); 
      props.put("group.id", KafkaMailProperties.groupId); 
      props.put("zookeeper.session.timeout.ms", "400"); 
      props.put("zookeeper.sync.time.ms", "200"); 
      props.put("auto.commit.interval.ms", "1000"); 
      return new ConsumerConfig(props); 
} 

public void run() { 
      Map<String, Integer> topicCountMap = new HashMap<String, Integer>(); 
      topicCountMap.put(topic, new Integer(1)); 
      Map<String, List<KafkaStream<byte[], byte[]>>> consumerMap = consumer.createMessageStreams(topicCountMap); 
      KafkaStream<byte[], byte[]> stream = consumerMap.get(topic).get(0); 
      ConsumerIterator<byte[], byte[]> it = stream.iterator();
      while (it.hasNext()) 
      System.out.println(new String(it.next().message())); 
}

上面的代码演示了基本的消费者API。正如我们前面提到的,消费者需要设置消费的消息流。在Run方法中,我们进行了设置,并在控制台打印收到的消息。在我的项目中,我们将其输入到解析系统以提取OTC定价。

在当前的质量保证系统中,我们使用Kafka作为消息服务器用于概念验证(Proof of Concept,POC)项目,它的整体性能优于JMS消息服务。其中一个我们感到非常兴奋的特性是消息的再消费(re-consumption),这让我们的解析系统可以按照业务需求重新解析某些消息。基于Kafka这些很好的效果,我们正计划使用它,而不是用Nagios系统,去做日志聚合与分析。

总结

Kafka是一种处理大量数据的新型系统。Kafka基于拉的消费模型让消费者以自己的速度处理消息。如果处理消息时出现了异常,消费者始终可以选择再消费该消息。

英文原文:Apache Kafka: Next Generation Distributed Messaging System

Posted in kafka | Leave a comment