好奇心驱动的无聊发现

作为 github+x 双料闲逛爱好者，经常能发现一些有趣的项目，大部分都没有机会在工作中用到，只觉有趣，记录在此。

Dragonfly：Redis 的平替

Dragonfly is a simple, performant, and cost-efficient in-memory data store. Dragonfly is fully compatible with Redis APIs but without the Redis management complexity.

名气很大，c++开发，号称全面全面兼容 redis, 就是说如果以前在代码里面使用了redis 的sdk，将 redis 替换成 dragonfly，不用改一行代码，讲真，有点厉害了

docker run -p 6379:6379 --ulimit memlock=-1 docker.dragonflydb.io/dragonflydb/dragonfly

使用go跑一个样例

package main

import (
  "context"
  "fmt"

  "github.com/redis/go-redis/v9"
)

func main() {
  ctx := context.Background()

  rdb := redis.NewClient(&redis.Options{
    Addr:   "localhost:6379",
    Password: "", // no password set
    DB:     0,  // use default DB
  })

  err := rdb.Set(ctx, "key", "value", 0).Err()
  if err != nil {
    panic(err)
  }

  val, err := rdb.Get(ctx, "key").Result()
  if err != nil {
    panic(err)
  }
  fmt.Println("key", val)

  val2, err := rdb.Get(ctx, "key2").Result()
  if err == redis.Nil {
    fmt.Println("key2 does not exist")
  } else if err != nil {
    panic(err)
  } else {
    fmt.Println("key2", val2)
  }
  // Output: key value
  // key2 does not exist
}

果然没有问题，样例过于简单，并不能说明生产环境就可用 dragonfly 完全替代 redis，毕竟 redis 相比而言更成熟，生态也要更好一些。

Redpanda: Kafka 的替代品

Redpanda is a simple, powerful, and cost-efficient streaming data platform that is compatible with Kafka APIs but much less complex, faster and more affordable. Get started in seconds with Redpanda Serverless

这个就没有上面 redis 说的那么夸张了，毕竟没有fully compatible 这么强劲的字眼

发现 redpanda 还是在去年，彼时笔者刚好在团队推动轻量化去 kafka 的运动，在笔者团队的业务场景下，完全没有必要使用 kafka 这种消息中件间，但是历史债(屎)务(山)过重，再加上业务繁忙，去 kafka 优化级滞后了。一向对重量型的 kafka 心生厌恶，于是偶然间发现了redpanda.

使用 docker-compose 启动：

version: "3.7"
name: redpanda-quickstart-one-broker
networks:
  redpanda_network:
    driver: bridge
volumes:
  redpanda-0: null
services:
  redpanda-0:
    command:
      - redpanda
      - start
      - --kafka-addr internal://0.0.0.0:9092,external://0.0.0.0:19092
      # Address the broker advertises to clients that connect to the Kafka API.
      # Use the internal addresses to connect to the Redpanda brokers'
      # from inside the same Docker network.
      # Use the external addresses to connect to the Redpanda brokers'
      # from outside the Docker network.
      - --advertise-kafka-addr internal://redpanda-0:9092,external://localhost:19092
      - --pandaproxy-addr internal://0.0.0.0:8082,external://0.0.0.0:18082
      # Address the broker advertises to clients that connect to the HTTP Proxy.
      - --advertise-pandaproxy-addr internal://redpanda-0:8082,external://localhost:18082
      - --schema-registry-addr internal://0.0.0.0:8081,external://0.0.0.0:18081
      # Redpanda brokers use the RPC API to communicate with each other internally.
      - --rpc-addr redpanda-0:33145
      - --advertise-rpc-addr redpanda-0:33145
      # Mode dev-container uses well-known configuration properties for development in containers.
      - --mode dev-container
      # Tells Seastar (the framework Redpanda uses under the hood) to use 1 core on the system.
      - --smp 1
      - --default-log-level=info
    image: docker.redpanda.com/redpandadata/redpanda:v23.3.10
    container_name: redpanda-0
    volumes:
      - redpanda-0:/var/lib/redpanda/data
    networks:
      - redpanda_network
    ports:
      - 18081:18081
      - 18082:18082
      - 19092:19092
      - 19644:9644

docker stats 看下

4e4805f55942   redpanda-0                       0.91%     1.156GiB / 7.752GiB   14.92%    1.05kB / 0B      122MB / 618kB     3

这单实例启动即 1G 内存的占用也是让人望而生畏，以至于忘记它是 c++ 开发(讲道理，用啥语言开发真有那么重要？)。使用 go 跑了一下生产-消费者样例，兼容性看起来倒是没啥问题

FerretDB：MongoDB 替代品

FerretDB was founded to become the de-facto open-source substitute to MongoDB. FerretDB is an open-source proxy, converting the MongoDB 5.0+ wire protocol queries to SQL - using PostgreSQL or SQLite as a database engine.

这玩意最吸引我的地方在于: go 开发，可使用 SQLite 作为数据库引擎

docker run -d --rm --name ferretdb -p 27017:27017 -e FERRETDB_HANDLER=sqlite ghcr.io/ferretdb/all-in-one

但是仔细一想，似乎作用不大，不论是 SQLite 还是 PG 作为数据库引擎，都没有比单独部署 MongoDB 依赖更少，没有看到明显的优势。

Fabio

Fabio is an HTTP and TCP reverse proxy that configures itself with data from Consul.

玩 nomad 的时候发现的新玩意，写这篇文章的动机也是因为想了好久，没记起来 fabio，深刻明白好记性不如烂笔头。再次回顾这个项目时，发现最近一次 github 提交是两年前了，似乎不太活跃了，想到它最大的依仗是配置基于 consul ，这点跟我在前司力推的 traefik 相比似乎不值一提了，优势不在，在我的 timeline 上也甚少出现了。

Kamal

Kamal offers zero-downtime deploys, rolling restarts, asset bridging, remote builds, accessory service management, and everything else you need to deploy and manage your web app in production with Docker. Originally built for Rails apps, Kamal will work with any type of web app that can be containerized

我的偶像 DHH 力推的开源项目。该项目诞生时名字叫：MRSK，不知为何后来改为了Kamal 。记得项目刚出现时，我就试用了一下，不太容易上手，体验上感觉就是docker+ansible 的合体，不过是用 ruby 实现的。上个月又试用了一下，我才意识到 DHH 可能大概是一个强迫症吧：配置没有 git ，不能部署(难道是受 gitops 的影响，习惯蛮好，入门不友好); 镜像中心必须为 https (我怀的内网 harbor 还是 http 的)……依我之见，kamal 注定要小众了，没法与 K8s 竞争，从上手体验来说，也不如 nomad，甚至是 docker swarm，当然，这个领域，百花齐放也挺好的。

ZincSearch

ZincSearch . A lightweight alternative to elasticsearch that requires minimal resources, written in Go.

一个用 go 实现的轻量型 es。以前我总是会产生一些稀奇的想法，想要平替项目日志组件中的 es，因为 es 太费资源，太重了。后来才明白，哪有那么容易平替的，而且github上明确提到了 zinc 不适合日志搜索。

❗Note: If your use case is of log search (app and security logs) instead of app search (implement search feature in your application or website) then you should check openobserve/openobserve project built in rust that is specifically built for log search use case.

不是每个场景都是重量级的，至少，zinc 提供了另外一种可能性，相较于 es，这个项目还很年轻，我还没找到适合我的使用场景。

VictoriaLogs

VictoriaLogs is open source user-friendly database for logs from VictoriaMetrics.

我在调研日志时发现的，VictoriaMetrics 家出品的，这个项目野心很大：支持全文搜索，相较于 es 与 loki, 更易于使用，性能也更好。基于 VictoriaMetrics 在平替 prometheus 时优异表现，即使现在看 victorialogs 还很年轻，但，就是很期待它的发展。

metric、log 都有了，就差 trace了，这三者的大一统，有望由 VictoriaMetrics 提供一个完整好用的方案么，从生态看，希望蛮大的，我个人也挺看好的，未来，让时间来回答吧。

总结

好奇心是个好东西，就是会分散注意力，暗合《为什么伟大不能被计划》。

参考：

just for fun