百分点开源Cois多语言客户端.docxVIP

百分点开源Codis多语言客户端java，c++和python都可以使用了　　开源伴随着互联网的兴起影响着越来越多的人，它让程序员可以站在巨人的肩膀上，帮助企业更快速地进行研发。百分点作为大数据领域的践行者和引领者，也正在从开源受益者成为开源贡献者。　　开发背景Codis 作为分布式 Redis 解决方案，在百分点已经有4.8T的Codis内存空间用来存储推荐引擎、CookieMapping和用户画像的数据。在实际应用中，Codis集群为 线上业务提供了稳定、低延迟以及高吞吐的Key-Value存储服务，并支持在线业务长期稳定运行。　　百分点在很多业务场景都在使用Codis。作为内存KV服务从早期的memcached到Redis-Sentinel，再到现在的Codis云，很多产品和应用都需要使用不同的语言对KV服务完成调用，如Python、C++、 Java等。但遗憾的是，目前Codis官方只提供了Java的客户端，对多语言应用造成不便，所以百分点研发团队开发了C++和Python两种语言的客户端来满足大部分业务代码的需求。同时，也对Java的客户端做了修改，来防止多个业务使用同一个Codis集群带来的key冲突问题。　　我们已经将代码分享在开源社区，帮助更多的人、更方便地使用Codis。　　C++　　Python　　为什么选择Codis？　　选型影响着技术发展的方向，在选用Codis之前，我们曾对下面的组件做过对比和评测：　　Twemproxy：是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。这个方案顺理成章地解决了单个Redis实例承载能力的问题。当然，Twemproxy本身也是单点，需要用Keepalived做高可用方案。　　优点：这些年来，Twemproxy是应用范围最广、稳定性最高、最久经考验的分布式中间件。　　缺点：Twemproxy最大的痛点在于其使用了ketama一致性hash算法，无法平滑地扩容/缩容，甚至连修改配置都需要重启服务；Twemproxy另一个痛点是，运维不友好，甚至没有控制面板，对Redis集群的扩容/缩容都很难操作，或者说，Twemproxy更像服务器端静态sharding。有时为了应对业务量突增导致的扩容需求，甚至被迫新开一个基于Twemproxy的Redis集群。　　Redis-Cluster：Redis-Cluster在Redis3.0中推出，是与Codis同期发布的产品，支持Redis分布式集群部署模式，采用无中心分布式架构，所有的Redis节点彼此互联(PING-PONG机制)，内部使用二进制协议，优化传输速度和带宽，节点的fail是通过集群中超过半数的节点检测失效时才生效。客户端与Redis节点直连，不需要中间proxy层，也不需要连接集群所有节点，只需连接集群中任何一个可用节点即可，减少了代理层，大大提高了性能。Redis-Cluster把所有的物理节点映射到[0-16383]slot上，Cluster 负责维护node-slot-key之间的关系。目前Jedis已经支持Redis-Cluster。　　优点：部署简单，all-in-the-box，没有像Codis那么多概念、组件和依赖。　　缺点：因其是无中心化设计，导致程序难以编写；Cluster的数据存储模块和分布式的逻辑模块是耦合在一起的，整个集群高度耦合，很难对Redis集群进行无痛的升级；不支持multi-key的操作，也不支持pipeline；其对协议进行了较大的修改，对客户端不太友好，目前很多客户端中的程序已经写好，让业务方去更换Redis Client是不太现实的。虽然Redis-Cluster从方案选型上面比较占据优势，但稳定性方面还有待验证。　　Codis：是用Go语言编写的具有高性能的Redis集群解决方案，在很多公司已被广泛的使用，支持绝大多数的Redis命令，完全兼容Twemproxy。　　优点：Codis无疑是为解决Twemproxy缺点而出的解决方案，因此综合方面会优于Twemproxy很多。Codis引入了Group的概念，每个Group包括1个Redis Master及多个Redis Slave，这样做的好处是如果Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改配置文件；还可以轻松的升级、扩容和缩容；Dashboard页面还可以支持监控和集群管理。　　项目描述　　Codis-Client是为Codis写的Java、C++和Python的客户端，其中Java的客户端是基于Jodis开发的。　　（1）Codis-Client用循环和连接池的