マイクロサービス領域におけるredisの貢献度を説明する

前置き

redisといえば、皆さんの頭に浮かぶキーワードは、おそらく NoSQL、KV、ハイパフォーマンス、キャッシュ、などなど。しかし、今日の記事は別の観点、つまりマイクロサービスからスタートします。

この記事を書いた理由もインタビューの経験からで、ストレンジャーの候補者（つまり出会い系のストレンジャー）のインタビューで、彼は非常に興味深いと感じた点を述べました、彼はストレンジャーのredisは非常に広く使われており、通常のキャッシュに加えて、いくつかのシナリオも使用するNoSQLデータベースとして、さらにマイクロサービスのレジストリとして、redisを使って、RPC RPC呼び出しプロトコルで使用されていると言いました。 {その レジストリ

レジストリとしてのredisはdubboのソースコードで初めて知りましたが、redisをサービスディスカバリーに使っている会社は聞いたことがなかったので、あまり詳しく知りませんでした。

dubboでサービスディスカバリーにredisを使うのは非常に簡単で、jedis依存関係を導入してレジストリのアドレスをredisアドレスに変更するだけです。

<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
	<version>2.9.0</version>
</dependency>

dubbo.registry.address=redis://127.0.0.1:6379を指定します。

登録されたデータは以下のような感じで、タイプハッシュがあります。

/dubbo/${service}/${category} です。

として

/dubbo/com.newboo.sample.api.DemoService/dubbo/com.newboo.sample.api.DemoService

保存されたキーの下にあるハッシュデータ構造は、登録されたアップロードのURLで、値は有効期限です。

127.0.0.1:6379> hgetall /dubbo/com.newboo.sample.api.DemoService
1) "dubbo://172.23.233.142:20881/com.newboo.sample.api.DemoService?anyhost=true&application=boot-samples-dubbo&deprecated=false& dubbo=2.0.Dubbo=2.0.Dubbo://172.23.233.142:20881/com.newboo.sample.api-DemoService? 2&dynamic=true&generic=false&interface=com.newboo.sample.api.DemoService&metadata-type=remote&methods=sayHello&pid=19807 &release=2.7.8&side=provider×tamp=1621857955355"
2) "1621858734778"。

理論的には、レジストリはデータの保存、プッシュチェンジのリッスン、ハートビート検出という基本的な機能を満たすだけでよいのです。

redisが独自の機能を使ってレジストリを完成させている例として、dubboを取り上げます（例としてdubboバージョン2.7.8を取り上げます）。

サービス登録

• プロバイダは、サービス提供者のurlを /dubbo/${service} で、データ型はハッシュ、キーはプロバイダの url、値はキーの有効期限、デフォルトは 60s で、以下のように設定可能です。
• 書き込みが完了した後、データは次のように入力されます。 /dubbo/${service} をキーとして呼び出し publish コマンドは、初期化時に登録イベントプロバイダを公開し、すべての 1/2 expiration time (デフォルトは30秒)で
• プロバイダが再登録され、register イベントが投稿されます。

サービス発見

• マッチングを取得する /dubbo/${service}/* キー（ここでは keys コマンド)を使用すると、次のようになります。

  /dubbo/${service}/dubbo/${service}/code ,
  /dubbo/${service}for
  /dubbo/${service}/*
  The key taken for the
  hgetall
  to get the real provider list and configuration data, assemble and match
  Also, open a separate thread for each subscribed service, for
  /dubbo/${service}
  Execute
  psubscribe
  command to block and wait for an event to occur
  From the source code and testing, dubbo's redis registry cannot be used directly in a production environment for two reasons.
  uses the
  keys
  command, it will block the single-threaded redis, and all other commands will have to be queued while keys is executed
  Without the heartbeat detection feature, I tested that the provider was being
  kill -9
  The consumer is not aware of this after it is killed. But from the implementation point of view is to determine whether the service is available through the stored expiration time, that is, you need to compare the url corresponding to the value and the current time, if the expiration should be eliminated, but this part does not seem to be fully implemented
  Although dubbo's redis registry is not available for production, it does not affect the ability to build a production-ready registry, and Stranger is a good example.
  RPC call protocol
  The redis protocol as an RPC call protocol was also told to me by a fellow stranger, when I asked him two questions.
  Why did you choose the redis protocol as the RPC call protocol?
  /p 
  How does the redis protocol pass through a header like
  implicit parameter
  The answer to the first question is also rather unexpected, he said it is for cross-language calls, when I thought that only http, gRPC and other protocols to do cross-language, redis protocol cross-language is also the first time I heard. But on second thought, there's really nothing wrong with it. Which back-end language now doesn't implement the redis client?
  The redis protocol is cross-language, thanks to its very simple and easy-to-implement design.
  http://redisdoc.com/topic/protocol.html
  I'll give you an example of how simple the redis protocol is, from a project I've been following for a long time
  https://github.com/jdp
  It is a php implementation of the redis client with a single php file, the
  196 lines in total
  The 196 lines contain comments, variable definitions, link creation, etc. There is very little code to actually parse the protocol, and the request is encoded and sent using only
  17 lines of code
  and the only code returned by parsing is
  58 lines
  ! As described in the project description.
  simple, no-nonsense
  The second question was answered as I expected, from the level of the redis protocol can not support the implicit parameters like header for the time being, but the RPC framework of Stranger is self-developed, so they solve this problem at the framework level, serialization they choose
  json
  If you want to pass through the header parameters, the framework assembles the parameters into the transport body.
  Unfortunately, the implementation of the redis protocol in dubbo is not complete and cannot expose the redis protocol, it can only be called, so the test can only test the client connecting to the redis server to make get and set calls, which is not very meaningful.
  Summary
  redis is currently a very versatile storage component, and while it's not mainstream in the microservices space, it does give us a way to think that at least this path is possible.
  This article about the contribution of redis in the microservices domain is all about this. For more information about redis microservices, please search the previous articles of Scripting House or continue to browse the following related articles.