这里翻译一篇关于 Kafka 实践的文章，内容来自 DataWorks Summit/Hadoop Summit（Hadoop Summit）上一篇分享，PPT 见Apache Kafka Best Pratices，里面讲述了很多关于 Kafka 配置、监控、优化的内容，绝对是在实践中总结出的精华，有很大的借鉴参考意义，本文主要是根据 PPT 的内容进行翻译及适当补充。
继续阅读
继续阅读
作者归档：javahao123
java8 :: 用法 （JDK8 双冒号用法）
来自：黑客和白帽子的故事
::特性
jdk8中使用了::的用法。就是把方法当做参数传到stream内部，使stream的每个元素都传入到该方法里面执行一下，双冒号运算就是Java中的[方法引用],[方法引用]的格式是：
Redis集群的方案总结：客户端Sharding/Redis Cluster/Proxy
转载：分布式一致性算法（一）一致性哈希算法（consistent hashing）
转载：Jedis下的ShardedJedis（分布式）使用方法（一）
一、Redis集群
由于Redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经用Redis存储了超过1TB的数据）。Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。
一致性哈希算法（consistent hashing）
来自：一致性hash算法（consistent hashing）
一 基本场景
比如你有 N 个 cache 服务器（后面简称 cache ），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到 N 个 cache ；
hash(object)%N
一切都运行正常，再考虑如下的两种情况:
- 1 一个 cache 服务器 m down 掉了（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了
hash(object)%(N-1) ； - 2 由于访问加重，需要添加 cache ，这时候 cache 是 N+1 台，映射公式变成了 hash(object)%(N+1) ；
1 和 2 意味着什么？这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言，这是一场灾难，洪水般的访问都会直接冲向后台服务器；
再来考虑第三个问题，由于硬件能力越来越强，你可能想让后面添加的节点多做点活，显然上面的 hash 算法也做不到。
有什么方法可以改变这个状况呢，这就是 consistent hashing…
学完这100多技术，能当架构师么？（能）
来自：小姐姐味道
前几天，有个搞培训的朋友，和我要一份java后端的进阶路线图，我就把这篇文章发给了他《必看！java后端，亮剑诛仙》。今天，又想要个java后端目前最常用的工具和框架，正好我以前画过这样一张图，于是发给了他。虽然不是很全，但也希望得到他的夸奖。没想到… 继续阅读
一篇文章讲透分布式存储
来自：存储技术
分布式存储是一个大的概念，其包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等。本文局限在分布式文件系统等传统意义上的存储架构，对于数据库等不做介绍。
补充说明：（1）块存储可以认为是裸盘，最多包一层逻辑卷（LVM）；常见的DAS、FC-SAN、IP-SAN都是块存储，块存储最明显的特征就是不能被操作系统直接读写，需要格式化为指定的文件系统（Ext3、Ext4、NTFS）后才可以访问。优点：读写快（带宽&IOPS）；缺点：因为太底层了，不利于扩展。（2）补充一点，与块存储对应的是文件存储，Ext3、Ext4、NTFS是本地文件存储，NFS、CIFS是网络文件存储（NAS存储）；最明显的特征是支持POSIX的文件访问接口：open、read、write、seek、close等；优点：便于扩展&共享；缺点：读写速度慢。（3）对象存储，对象存储肯定是分布式存储，但分布式存储可能是分布式文件系统，不一定是对象存储；常见的对象存储开源实现有 Ceph 的RADOS、openstack的swift、AWS s3等，常见分布式文件系统，lustre、glusterfs、HDFS等；对象存储和分布式文件系统的表面区别：对象存储支持的访问接口基本都是restful接口、而分布式文件系统提供的POSIX兼容的文件操作接口；最本质的区别：分布式文件系统文件组织方式为目录树、对象存储采用的则是扁平的组织方式；对象存储不支持随机读取和写入，put和get操作都是针对的整个文件。相信使用过网盘的同学都了解。既然都是分布式存储，扩展性肯定都是没问题的。只是使用场景不同。
Mybatis架构与原理
来自：消失er
我们把Mybatis的功能架构分为三层：
(1)API接口层：提供给外部使用的接口API，开发人员通过这些本地API来操纵数据库。接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理。
(2)数据处理层：负责具体的SQL查找、SQL解析、SQL执行和执行结果映射处理等。它主要的目的是根据调用的请求完成一次数据库操作。
(3)基础支撑层：负责最基础的功能支撑，包括连接管理、事务管理、配置加载和缓存处理，这些都是共用的东西，将他们抽取出来作为最基础的组件。为上层的数据处理层提供最基础的支撑。
