ES是一个非常流行的基于lucene的搜索和分析引擎，它提供了resetful的api非常适用于搜索、推荐、日志分析等场景，社区生态丰富，是分布式架构中非常重要的一环。下面从一个docker-compose部署一个最小化集群,并用Kibana和cerebro可视化的来一窥它的能力。

version: '3.9'
services:
  cerebro:
    image: lmenezes/cerebro
    container_name: cerebro
    ports:
      - "9000:9000"
    command:
      - -Dhosts.0.host=http://host.docker.internal:9200 
      # 因为我是mac所以用host.docker.internal代替主机名
  kibana:
    image: docker.elastic.co/kibana/kibana:7.7.0
    container_name: kibana7
    environment:
      - I18N_LOCALE=zh-CN
      - XPACK_GRAPH_ENABLED=true
      - TIMELION_ENABLED=true
      - XPACK_MONITORING_COLLECTION_ENABLED="true"
      - ELASTICSEARCH_HOSTS=http://host.docker.internal:9200
    ports:
      - "5601:5601"
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.7.0
    container_name: es7_01
    environment:
      - cluster.name=cnblogs
      - node.name=es7_01
      - bootstrap.memory_lock=true  
      # 避免使用swap，减少磁盘IO
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"  
      # 防止JVM内存回收
      - discovery.seed_hosts=172.19.0.5,172.19.0.4
      # 默认ES只搜索本机的其他节点，如果节点在其他主机上则需要在这里给出地址
      - cluster.initial_master_nodes=es7_01,es7_02   
      # 初始化时符合主节点的节点方便选举
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - es7data1:/usr/share/elasticsearch/data
    ports:
      - 9200:9200

  elasticsearch2:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.7.0
    container_name: es7_02
    environment:
      - cluster.name=cnblogs
      - node.name=es7_02
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - discovery.seed_hosts=172.19.0.5,172.19.0.4
      - cluster.initial_master_nodes=es7_01,es7_02
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - es7data2:/usr/share/elasticsearch/data
    expose:
      - 9200


volumes:
  es7data1:
    driver: local
  es7data2:
    driver: local

networks:
  default:
    external: true
    name: es7net

运行上述代码前请先创建一个名为es7net的网络: docker network create es7net
下面是配置集群几个常见配置的原则

• bootstrap.memory_lock一般设置为true，避免使用swap
• ES_JAVA_OPTS中Xms和Xmx设置为一致，避免jvm内存重新分配
• cerebro起来比较快，kinaba很慢要等一下，多刷新就好了
• 运行上面的集群请至少保证docker拥有3g以上，因为Elasticsearch by default deploys with a 1GB heap，开始只使用了2g时就会出现内存不足导致es启动失败，如果是下面几种错误信息可以尝试增加内存

master not discovered or elected yet, an election requires a node with id 
或
master not discovered yet, this node has not previously joined a bootstrapped (v7+) cluster, and this node must discover master-eligible nodes 
或
max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

启动后可以按照以下步骤逐步检查部署

1检查ES运行状态

   http://localhost:9200/_cat/health?v

2 登录cerebro

cb的概览非常适合作为看板，对于刚接触es的同学来说能更好的理解es集群的状态，虽然它不是官方的

3 登录kinaba,官方

官方样例数据就可以创建非常漂亮的看板/报表

可以查看非常细节的数据，并支持完整的索引操作

接上文：《高效的的关键字查找和检测（哈希表和Trie前缀树和FastCheck）在实际使用中的性能》

动态语言是很慢的，它更多的是为了提高开发效率，这里的关键字过滤算法在生产环境中用原生python达到125ms 2千万字/每秒已经够用了。那么是不是可以适当的优化再快一点？

Cython，没事cython一下，带你飞

cython能把大部分python代码改为静态的c实现，甚至你可以混合c和python一起写。不过现实是大部分的pythoner如果碰到性能问题要么用go要么就是用csharp，很少去写cython。下面是用cython编译后的测试结果：

提升39%，马马虎虎，也可能跟Tool.Good源码的实现有关。此时文本的处理量已经到了3400万/每秒,用是够用了，那么能不能更快一点？

C# 是时候展现你的实力了

Tool.Good作者明显是一位纯粹的csharpner, 既然已经实现了3亿效率的代码为什么不拿来用呢。这里作为对比，我先写了一个参照的测试程序，测试环境与前文相同。代码如下

using System;
using ToolGood.Words;
namespace KeywordTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = System.Diagnostics.Stopwatch.StartNew();
           
            string post = System.IO.File.ReadAllText(@"D:\Projects\Opensource\ToolGood.Words\csharp\KeywordTest\sample_post");

            string[] spams = System.IO.File.ReadAllLines(@"D:\Projects\Opensource\ToolGood.Words\csharp\KeywordTest\SpamWordsCN.min.txt");

            StringSearch iwords = new StringSearch();
            iwords.SetKeywords(spams);
            stopwatch.Start();
            for (var i = 0; i < 500; i++)
            { var f = iwords.FindFirst(post); }

            stopwatch.Stop();
            var s = stopwatch.ElapsedMilliseconds;
            Console.WriteLine("测试用时（ms）：" + s);
        }
    }
}

Csharp性能都这样了更别说C了，那么为什么能比cython快那么多呢。这里分两部分原因，一部分性能浪费在python和c的交互上，另一部分在cython编译时的类型推断和生成的代码优化不够，大量使用的还是pure python。咱不纠结这个，手头有这么快的csharp不用简直浪费，一脚踢走cython，黏上csharp，让它飞的更高~

Pythonnet 闪亮登场

这可是个好东西，.net基金会项目，官方身份，神秘可靠。有了它使得python和.net交互变得简单。这里需要一提的是目前稳定版2.5.2还只支持.net 4.0，至于.net core 3和.net5需要手动安装master分支上的3.0.0dev，实现方式 也有所不同，下面是代码：

def test2():

    from clr_loader import get_coreclr
    from pythonnet import set_runtime

    rt = get_coreclr("./runtimeconfig.json")
    set_runtime(rt)
    import  clr
    clr.AddReference('ToolGood.Words')

    import clr
    from System import String
    from ToolGood.Words import StringSearch
    stringSearch=StringSearch()

    with  open('./sample_post',encoding='utf-8') as f:
        test_post = f.read()
    from System.Collections.Generic import List
    spam_words=List[String]()
    with open('././SpamWordsCN.min.txt',encoding='utf-8') as f:
        for line in [line.rstrip() for line in f]:
            spam_words.Add(String(line))

    stringSearch.SetKeywords(spam_words)
    import time
    start = time.time()
    times = 500
    while times > 0:
        f = stringSearch.FindFirst(test_post)
        times -= 1
    end = time.time()
    print('程序运行时间:%s毫秒' % ((end - start) * 1000))

{
  "runtimeOptions": {
    "tfm": "net5.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "5.0.2"
    }
  }
}

事实上如果增加压力还能提高性能，因为交互部分压力越大性价比越高。此时的处理速度已经到了2.5亿/每秒。那么能不能再快点？烦不烦，其实也不烦，生产中怎么可能不并行呢，动不动八核十几核的，线程再来double一下，妥妥的几十亿。

为什么不直接用csharp直接做服务

当然可以，如果负载确实高换纯csharp顶上，还不够再换go，还不够把分布式也弄上。但现实是高负载的需求可能永远不会到来，为什么不把时间省下来去做更有意义的事呢？

引用文地址：https://fastapi.tiangolo.com/async/

前言：fastapi是一个广泛使用的高效的restful api框架，他的作者在这篇讲解框架中使用async的说明详细举例解释了异步编程、并发和并行的区别，堪称经典，于是手痒总结如下（不敢说翻译）

async使用指导：

• 如果这个请求比较慢，比如连接数据库读取数据、文件IO、rpc调用等一般加上async，我想普通项目里大部分请求都会多多少少跟数据库打交道，所以加的往往比较多；
• 比较快，稳定的使用def即可，也可以把没有上面情况调用的都按照这类处理；
• 分不清加不加就不加，放心这不是什么大的问题，我在测试中发现不加效率高一丢丢，毕竟async是要开销的，特别适合首页这种重缓存的场景；

异步编程：

Asynchronous Code是给语言层面提供一种方式描述程序在某一点等待慢操作比如慢文件读写或者需要其它资源协作，从而让计算机可以在等待中去执行其它工作。文中作者详细列举了相对于cpu和内存操作来说慢的多的慢操作如：

• 网络通信
• 文件读写
• 远程api调用如rpc调用
• 数据库操作和查询

异步是相对同步编程来说的，在执行顺序上并没有改变。实际效果就是同一台机器如果有比较多的慢操作使用异步编程可以提高吞吐率。这里再吐槽一下，大部分语言比如python、csharp、go等的async都是协程实现的，只有java是线程实现的。代价：进程>线程>协程，java不是不能用协程来实现完全是因为历史包袱，线程相对也不会丢失太多的性能。

并发和汉堡的故事

异步的描述通常称之为并发，它跟并行不是一回事，虽然他们经常都是描述在同一时间内处理不同的事情。在细节上两者大不相同，可以下面就是用汉堡的故事来理解：
你带着心爱的小妹挤进忙碌的快餐店，排队等着付钱买汉堡。
轮到你的时候，你付钱买了两个很赞的大汉堡。
付钱
收银员告诉厨房新的订单，哪怕厨房还在准备前面的汉堡
收银员告诉你取餐号码
然后你和小妹找张桌子谈谈人生谈谈理想，因为汉堡太赞需要时间慢慢做
你趁这个时间对小妹一阵猛夸，如何如何的魅力，如何如何的动人
轮到你了后去柜台取走汉堡
然后就可以和小妹一起慢慢品尝

设想一下，如果是计算机中这个故事会怎么样
排队的时候你可能需要被迫傻等，而不是做点有意义的事比如调情，因为收银员得一个个收钱
当轮到你的时候你才会忙着看菜单，点单，付钱，确认找回来的钱，就算这样你还是没有拿到汉堡，只能去找张桌子等待
直到这个时候你才可以做些有意义的事
因为你有取餐号，所以直到显示屏上通知你可以取餐都不用担心你的汉堡被偷了
最后你去柜台取餐，道谢后算是完成任务并开始任务品尝美味的汉堡。

并行汉堡

现在设想下如果不是并发，而是并行，那么你跟你的小妹来到汉堡店就不是排一个队伍了，而是并行比如8个队伍，没有收银员只有厨师。
你前面每个人都在等他们的汉堡，拿到汉堡后才能离开柜台，厨师只有交出汉堡后才会收下一位的订单。
终于等到你了，付钱，然后等待厨师去厨房做汉堡
没有取餐号，因为没人在你前面，这时你和你的小妹只能干一件事就是确保自己在第一个不让别人抢走汉堡
等待很久以后才能拿走，这里几乎没有时间给你调情，真是个悲伤的故事。
在这个并行场景中你和你的小妹是两个处理器都等待了很久。
快餐店需要8个处理器，而并发下只需要2个。
当然，这个体验肯定不好。

汉堡总结

这个场景中有非常多的等待，所以它更适合并发系统。这也是web程序遇到的问题。太多太多的用户，但是你的服务器要等待不那么快的连接，然后还要等待回应。虽然这里的等待是以毫秒记，但是加起来就很恐怖了。所以这就是为什么Web APIs都用异步。
对于大多数现有的python框架都是在异步特性出现前设计的，所以他们大多以并行的方式实现异步，性能不强。

是不是并发比并行更好？

不，使用场景不同，并发适合web程序，但不是所有。比如科学计算，图形/音频处理,机器学习，深度学习等都适合并行计算。并行计算主要解决cpu瓶颈。