首页 / JSON / sphinx源码阅读之json,hashtable配置分析器

sphinx源码阅读之json,hashtable配置分析器

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了sphinx源码阅读之json,hashtable配置分析器，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含9225字，纯文字阅读大概需要14分钟。

内容图文

前言 读了 sphinx 的读取配置文件的代码， 心中有一个疑问： sphinx 为什么要自己造轮子呢？ 难道现在 sphinx 一直没人升级维护也是这个历史包袱的原因吗？ 不管哪么多了，先来看看 sphinx 怎么分析配置文件以及储存配置文件的吧。 配置文件规则 下面是一个

sphinx源码阅读之json,hashtable配置分析器 - 文章图片 sphinx源码阅读之json,hashtable配置分析器 - 文章图片

前言

读了 sphinx 的读取配置文件的代码， 心中有一个疑问： sphinx 为什么要自己造轮子呢？
难道现在 sphinx 一直没人升级维护也是这个历史包袱的原因吗？

不管哪么多了，先来看看 sphinx 怎么分析配置文件以及储存配置文件的吧。

配置文件规则

下面是一个简单的还有增量索引的 sphinx 配置文件。
其中 inc_source 继承 base_source 源。
inc_index 继承 inc_index 索引。 然后又简单的配置了 indexer 和 searchd 选项。

source base_source {
    type            = mysql
    sql_host        = 127.0.0.1 
    sql_user        = test 
    sql_pass        = test
    sql_db          = d_test 
    sql_port        = 3306
    sql_query_pre= SET NAMES utf8
    sql_query = select c_id, c_title, c_content, c_comments, c_mtime FROM t_post;
    sql_attr_uint = c_comments
    sql_attr_string = c_title 
    sql_field_string = c_content
    sql_field_string = c_mtime
}
source inc_source : base_source{
    sql_query_pre = SET NAMES utf8
    sql_query = select c_id, c_title, c_content, c_comments FROM t_post where c_mtime >=(SELECT c_mtime FROM t_post_inc where c_id = 1) ; 
}
index base_index {
    source          = base_source 
    path            =  var/data/base_index
    docinfo         = extern
    charset_type        = zh_cn.utf-8 
    charset_dictpath =  etc/  
    ngram_len = 0
}
index inc_index : base_index{
    source = inc_source
    path =  var/data/inc_index
}
indexer{
    mem_limit       = 32M
}
searchd{
    listen          = 9312
    listen          = 9306:mysql41
    log         =  var/log/searchd.log
    query_log       =  var/log/query.log
    pid_file        =  var/log/searchd.pid
}

配置文件数据结构

对于上面的配置文件，我们是可以用一个 json 来表示的。
也就是就是一系列的递归的 key-value 而已。
假设整个文件就是一个根的话，那么第一级儿子有 source, index, indexer, searchd 四个儿子。
然后对于 index 和 source 的儿子是个数组，数组的每个位置都是一个对象，因为可以配置多个 index 和 source.
对于 indexer 和 searchd 的儿子是一个对象。 上面所说的对象就是一系列的 key-value 叶子节点。

对于 根 节点， sphinx 使用一个 hash 储存，实际上所有的节点都是使用 hash 来储存的。

/// config (hash of section types)
typedef SmallStringHash_T < CSphConfigType >    CSphConfig;

对于第二级节点， 又是另一个 hash 对象。

/// config section type (hash of sections)
typedef SmallStringHash_T < CSphConfigSection > CSphConfigType;

CSphConfigSection 这一级需要表示两种类型： 叶子节点 和 数组。
于是不是使用简单的 hash 对象， 而需要在 hash 对象基础上封装一层。
实际上 sphinx 不是封装了一层，而是封装了 三层。

/// config section (hash of variant values)
class CSphConfigSection : public SmallStringHash_T < CSphVariant >;
/// small hash with string keys
template < typename T >
class SmallStringHash_T : public CSphOrderedHash < T, CSphString, CSphStrHashFunc, 256 >;
/// simple dynamic hash
/// implementation: fixed-size bucket + chaining
/// keeps the order, so Iterate() return the entries in the order they was inserted
/// WARNING: slow copy
template < typename T, typename KEY, typename HASHFUNC, int LENGTH > class CSphOrderedHash;

最后一层终于看到基类了。

json 与 hash table

看到这里， 我们发现所有的节点都继承于 SmallStringHash_T 这个模板类。
这个类帮我们实现了储存 key-value 的方法。

那他是怎么实现的呢？
先说说需求吧，我们有一些列的 key-value, 然后我们实现快速添加和查找。

这个怎么看起来好熟悉的样子？
对了，这不正是 hash table 做的事情吗？
前几天我写了两篇文章 hash table 研究与实现 和 memcached 源码阅读之 hash table .
难道这次又要写一个 sphinx 的 hash table 吗？

想要知道一个 key-value 是怎么储存的，只需要看看它的 add 函数就可以了。
下面就先来看看 sphinx 的 add 操作。

/// add new entry
/// returns true on success
/// returns false if this key is already hashed
bool Add ( const T & tValue, const KEY & tKey ){
    unsigned int uHash = ( (unsigned int) HASHFUNC::Hash ( tKey ) ) % LENGTH;
    // check if this key is already hashed
    HashEntry_t * pEntry = m_dHash [ uHash ];
    HashEntry_t ** ppEntry = &m_dHash [ uHash ];
    while ( pEntry ){
        if ( pEntry->m_tKey==tKey )return false;
        ppEntry = &pEntry->m_pNextByHash;
        pEntry =   pEntry->m_pNextByHash;
    }
    pEntry = new HashEntry_t;
    // do other thing
}

好吧，看到上面那个循环，我又想起了 memcached 源码阅读之 hash table 顶端的封面图了。
典型的链表式 hash 。

什么意思呢？
hash 遇到冲突了，以链表的形式储存即可。

这里就不多说 sphinx 的 hash table 了。
然后我们通过 hash-table 的递归， 我们就可以实现自己的 json 了吧。

唯一的不同时 json 储存的类型比较复杂， 而我们的类型比较单一， 叶子节点的值都是 string 和 数字。
不过这并影响我们自己实现 json 的那些功能。

配置文件解析器

看到这里，我们就会发现储存 配置信息并不是难题， 现在的难题是怎么把这个配置文件转化为我们储存的数据结构。

其实我们的配置文件还是蛮复杂的，当然我是和 ini配置文件对比的。
像现在的配置文件， 基本上都是这个形式，而且一般内部还要再嵌套几层。
不管配置文件有多复杂， 对于我们这个配置文件解析器来说，都一样的。

为什么这个说呢?
作为修电脑专业，大家上大学的时候都学过编译原理这门课吧。
那门课的最初几张就是讲这个解析器的基本原理的，即自动机。

我们定义一套规则，配置文件按这套规则配置，解析器按照这套规则解析即可。

说了这个多，还是自动机 的状态吧。

sphinx 的配置文件可以用下面这几个状态表示。

enum { S_TOP, S_SKIP2NL, S_TOK, S_TYPE, S_SEC, S_CHR, S_VALUE, S_SECNAME, S_SECBASE, S_KEY }

S_TOP 是开始的状态。
而 S_SKIP2NL 是注释的状态，配置文件内一般只支持行注释，所以注释标示符后面的内容我们往往忽略掉。
当然一般第一行会有特殊的用处，sphinx 也有特殊的用处。
但是这个我查了文档没有找到， sphinx 源码有大概意思是可以执行指定程序，参数是这个配置文件。
我们不管这个了。我们就假设没有这一项就行了。

一般 S_TOP 状态下，忽略空白后，第一个遇到的就是 source， index, searchd, indexer 这四个串中的一个了。
所以 S_TOP 会先调用 S_TOK 去读取一个单词(token), 然后转到 S_TYPE 状态。

S_TYPE 会根据读取得到的字符串而分出两个状态来。
其中 source 和 index 会转向 S_SECNAME 状态， 而 indexer， searchd， 和 common 会转向 S_SEC 状态。

为什么要这么分呢？
那是因为 source 和 index 后面会有个名字， 而其他的没有名字，直接就是 key-value 了。

S_SEC 状态简单， 我们先看 S_SEC 状态的转移。
当然，在转移到 S_SEC 状态前，我们需要读取一个左大括号 "{", 读取一个确定的单词由状态 S_CHR 完成。
在 S_SEC 中，我们需要做的是读取一个 key-value, 其中 key-value 用 等号分割。
于是第一次遇到非空字符，我们需要先读取 key, 于是 S_SEC 转移到 状态 S_KEY。
而遇到结束符 "}" 代表这个配置结束。

状态 S_KEY 是一个token, 所以我们需要调用 S_TOK 状态来完成读取这个 token.

在 S_KEY 中，我们需要先读取 一个确定的等号 "=" (状态 S_CHR)， 然后读取 value, 于是转移到 状态 S_VALUE。

在状态 S_VALUE 我们需要先把读到的 value 存起来， 然后在遇到结束符的时候调用添加 key-value 的函数。

这个时候我们就完成了读取 S_SEC 状态的一个 key-value，直到读取到结束符 "}" 我们就回到了 S_TOP 状态。

当 S_TOP 转向 S_SECNAME 状态时，我们需要先读取 配置名字。
于是我们先转向 S_TOK 状态读取一个 token.
然后会遇到两种情况：一种遇到了 开始符号 "{"，我们转向 状态 S_SEC。
另一种情况我们遇到 ":", 意思是这个配置要集成与之前的某个配置。
于是我们需要先读取一个 base 的名字，即转向 状态 S_SECBASE 。

S_SECBASE 状态先转向 S_TOK 来读取一个 base 的名字。
然后会把 名字为 base 的配置复制到当前配置。
接着就可以用 S_CHR 读取开始符 "{" 并转向 状态 S_SEC 了。

这样状态自动机就完成了。

具体可以参考下面的这幅图：

sphinx源码阅读之json,hashtable配置分析器 - 文章图片

简单的状态如下

#define LOC_PUSH(_new) { eStack[iStack++] = eState; eState = _new; }
#define LOC_POP() { eState = eStack[--iStack]; }
#define LOC_BACK() { p--; }
for (;; p++) {
    // if this line is over, load next line
    // handle S_TOP state
    if (eState == S_TOP) {  
        iToken = 0;
        LOC_PUSH(S_TYPE);
        LOC_PUSH(S_TOK);
        LOC_BACK();
        continue;
    }
    // handle S_SKIP2NL state
    if (eState == S_SKIP2NL) {
        LOC_POP ();
        p = pEnd;
        continue;
    }
    // handle S_TOK state
    if (eState == S_TOK) {
        if (!sphIsAlpha(*p)) {
            LOC_POP ();
            sToken[iToken] = '\0';
            iToken = 0;
            LOC_BACK();
            continue;
        }
        if (!iToken) {
            sToken[0] = '\0';
        }
        sToken[iToken++] = *p;
        continue;
    }
    // handle S_TYPE state
    if (eState == S_TYPE) {
        if (IsPlainSection(sToken)) {
            if (!AddSection(sToken, sToken))break;
            sToken[0] = '\0';
            LOC_POP();
            LOC_PUSH(S_SEC);
            LOC_PUSH(S_CHR);
            iCh = '{';
            LOC_BACK();
            continue;
        }
        if (IsNamedSection(sToken)) {
            m_sSectionType = sToken;
            sToken[0] = '\0';
            LOC_POP ();
            LOC_PUSH(S_SECNAME);
            LOC_BACK();
            continue;
        }
    }
    // handle S_CHR state
    if (eState == S_CHR) {
        LOC_POP ();
        continue;
    }
    // handle S_SEC state
    if (eState == S_SEC) {
        if (*p == '}') {
            LOC_POP ();
            continue;
        }
        if (sphIsAlpha(*p)) {
            LOC_PUSH(S_KEY);
            LOC_PUSH(S_TOK);
            LOC_BACK();
            iValue = 0;
            sValue[0] = '\0';
            continue;
        }
    }
    // handle S_KEY state
    if (eState == S_KEY) {
        LOC_POP ();
        LOC_PUSH(S_VALUE);
        LOC_PUSH(S_CHR);
        iCh = '=';
        LOC_BACK()
        continue;
    }
    // handle S_VALUE state
    if (eState == S_VALUE) {
        if (*p == '\n') {
            AddKey(sToken, sValue);
            iValue = 0;
            LOC_POP ();
            continue;
        }
        if (iValue < iValueMax) {
            sValue[iValue++] = *p;
            sValue[iValue] = '\0';
        }
        continue;
    }
    // handle S_SECNAME state
    if (eState == S_SECNAME) {
        if (!sToken[0]) {
            LOC_PUSH(S_TOK);
            LOC_BACK();
            continue;
        }
        AddSection(m_sSectionType.cstr(), sToken);
        sToken[0] = '\0';
        if (*p == ':') {
            eState = S_SECBASE;
            continue;
        }
        if (*p == '{') {
            eState = S_SEC;
            continue;
        }
    }
    // handle S_SECBASE state
    if (eState == S_SECBASE) {
        if (!sToken[0]) {
            LOC_PUSH(S_TOK);
            LOC_BACK()
            ;
            continue;
        }
        // copy the section
        LOC_BACK();
        eState = S_SEC;
        LOC_PUSH(S_CHR);
        iCh = '{';
        continue;
    }
}

原文地址：sphinx 源码阅读之json, hash table配置分析器, 感谢原作者分享。

内容总结

以上是互联网集市为您收集整理的sphinx源码阅读之json,hashtable配置分析器全部内容，希望文章能够帮你解决sphinx源码阅读之json,hashtable配置分析器所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/555174.html

来源：【匿名】