I.はじめに
Redisの小規模パートナーは不慣れであってはならない、Redisのは、主に、システムのスループットを高めるために、高い同時実行の下で負荷分散DBリソースを解決するために使用される必須の分散キャッシング・ミドルウェア・システムです。
Redisのは、文字列（String）を、リスト（一覧）、ハッシュ（ハッシュ）、セット（コレクション）、ZSET（順序集合）を複数のデータ型をサポートし、異なるタイプの異なるビジネス要件に適用することができます。
RedisのRedisのクラスタの展開も、高可用性とデータの容易な展開を強化します。
私たちの仕事の知識ポイントが頻繁に使用フォーカスを把握するために、すべてのRedisの知識、が、また、オンラインプレゼンテーションの多くの上に、古い区が導入されていません。
今日では、古い区シェアRedisのエンタープライズアプリケーションは、緯度の実際のビジネスから、我々は通常、どのような問題を見てのRedisを使うのか？どのように解決するには？
二、Redisのクラスタ部門
今、私たちのビジネスは、製品は確かに複数のプロジェクトを行い、または大規模なプラットフォームは、ビジネスの多くの行があるでしょう。さまざまなプロジェクトや事業ラインは確かに別のチーム開発です。我々はすべてのRedisを使用することを、どのようにそれを分割するには？
-
独立Redisのクラスタ
このプログラムは異なるRedisのクラスタと異なるビジネスである、いくつかの小さなプロジェクトやビジネスの行のためのこの方式は複雑ではない、とのRedisキャッシュ範囲を使用しない、それはサーバリソースの無駄、と増加運用・保守作業であります量。
もちろん、良い、それは、Redisのリソースの独立性である、干渉しない。通常、大規模なプロジェクトで使用されます。
-
公共Redisのクラスタ
このスキームは、いくつかの企業はRedisのリソースの使用率を高め、Redisのクラスタを共有することです。
課題
一般的なビジネス、ビジネスのラインが大きくないので、我々は、公共のRedisのクラスタを使用する一般的なビジネスの異なるラインでは、クラスタを分離する必要はありません。リソースのこのようRedisの完全な使用が、しかし、いくつかの問題があるでしょう。
第四に、どのようにビジネスを区別するために
マルチサービス利用Redisのうち、キャッシュキーの多くは、単にようなビジネスのどの部分であり、これはキーを知ることはできませんが存在します。
KEY：ユーザー：1000、ユーザー：ブック、ブック、利用者：よう：ブック、ブック：ユーザー;でもキーの競合があるかもしれません。
Redisのは、合理的な設計と計画の使用における発展の鍵であるが、二つの異なるチーム、技術と管理は、仕様書は、異なるビジネスグループとの間で、規範の実装が知られていない場合でも、同じではありません。
第五に、どのようにエレガントな拡大
Webサービスの開発に我々は、同様のjedisクライアント接続Redisのサーバーを使用しますが、Redisのクラスター・アドレスは、設定ファイルに追加されます。システムはRedisの負荷が高すぎる、またはRedisのデータ容量が必要な遭遇した場合でも、当社はRedisのサーバーを追加する必要があります。その後、Redisのクラスタの変化プロファイルを再し、アプリケーションを再起動する必要があります。
、上記の方法が低すぎるかどうかはアプリケーションを再起動する必要があり、非常に多くのアプリケーションが再起動を必要とし、あまりにも面倒ではない、との場合は、ビジネスで区別することができない場合、どのようなビジネスアプリケーションの再起動を知りません。
第六に、どのように変わりました
実際のビジネスシナリオでは異なる事業者、別のチーム、別の開発者が、私たちはバグが存在する管理者を避けることができないので、ラインはどうなる問題の種類を予測することはできませんか？以下のような：発見のRedisクラスター不安定な状況、CPUの負荷が非常に高く、その後、どのように我々はそれを原因となったビジネスを知っていますか？
これは公共のRedisのクラスタがあるので、これは非常に重要である、クラスタは一度それが全体のビジネスに影響を与えるだろう、ハングアップ。
異常を切断する方法七、
我々は非常に迅速になど、疑わしいビジネスやアプリケーションサーバを作るために彼らは私たちの公共Redisのクラスタを訪問できるように切り捨てられ、その後どのように、異常なトラフィックによって生成された本番環境であり、あるいはどのアプリケーションサーバが生成されると調査とそのアクセス権の回復の理由。
VIIIソリューション
小さなパートナーはどのように感じている、こちらを参照してください？を利用するには、インターネット上で述べたように、これらの問題についての考えはありませんが、動作していない、直接作業。
上記の問題を解決する方法を、自分自身に考えていないですか？
旧区ここに私たちのソリューションを伝えるために、ライン上の全体のコードや他の旧区の特定のオープンソースプロジェクトRB-キャッシュした後、他の人になります。
九、差別化サービス
この問題を解決するためには比較的簡単です、それは当社の既存のクライアントツール、二次包装にあり、
図は、二次パッケージインタフェースが定義されています
実際には、原則としては、管理が比較的簡単で、管理が敷設され、ビジネスへの強制的なアプローチは、開発者は、各事業は、開発の前にある差別化できますです。
プロジェクト管理、業務の合理的な分割は、あなたが簡単な方法で再パッケージ化することができた場合は、設定ファイル内のビジネス・サービスは、あなたがたび事業のパラメータを渡す必要はありません。
十、优雅扩容
解决这个问题，其实原理比较简单，就是程序如果能够知道Redis集群地址产生了变化，重新设置一下jedis客户端的连接配置。现在的问题就是如何知道Redis集群地址发生了改变？
我们可以采用把Redis的集群地址配置在zookeeper中，应用在启动的时候，获取zk上的集群地址的值，进行初始化。如果想要改变集群地址，要在zk上面进行设置。
zk重要的特性就是监听特性，节点发生变化，就会立刻把变化发送给应用，从而应用获取到值，重新设置jedis客户端连接
十一、发现异常
发现异常这个问题，其实就是一个监控的问题，我们需要把各个客户端使用Redis的情况进行监控。怎么监控？
需要一个监控工具，这个监控工具网上有几个，推荐使用小米的open-falcon，自行搭建改监控系统，搭建比较复杂，但功能比较强大，很多公司都在使用。
当然小伙伴们可以用别的监控工具，只要数据上报协议，和监控报表输出功能即可，当然也要有报警的功能，及时给运维人员报告
再使用Aop拦截Redis操作类，拦截Redis操作，把相关数据进行封装。每隔1分钟把这些数据上报到open-falcon平台中。具体监控什么数据，由业务决定，一般要把设置的key，业务，操作时长，哪个客户端IP发起的，都需要监控。
在可以设置相关的报警规则，如：某个key一直被调用，在一段时间内操作次数太高。这样就可以方便排查哪些key导致cpu负载太高，就可以去看一下设置这个key的代码，有没有什么问题？是不是死循环等问题？
十二、截断异常
在上面的发现异常的基础上面，如果发现某些业务应用，不正常，就可以立即发起截断该客户端的请求，这样可以保证其他业务不受影响。这里我们使用客户端方式去实现截断。原理也很简单，在Redis二次封装的类中，我们需要判断本机是否在黑名单中，如果存在，则无法操作方法，或报异常。
如何知道黑名单的变化，跟优雅扩容那个Redis集群地址的改变，方案一样。
十三、总结
在企业应用中，小伙伴们要经常去思考，业务进行中，如何方便管理，及时发现问题，是非常重要的。这也是很多管理者经常忽略的，都只是先把功能完成了，而不顾管理和监控。希望这篇文章能够帮助大家，从另一个纬度发现问题。谢谢！！！