Jedis之ShardedJedis一致性哈希分析 - 鑫鑫哥哥呀的个人页面 - 开源中国社区
ShardedJedis通过一致性哈希实现的的分布式缓存。主要思路：
redis服务器节点划分：将每台服务器节点采用hash算法划分为160个虚拟节点(可以配置划分权重)
将划分虚拟节点采用TreeMap存储
对每个redis服务器的物理连接采用LinkedHashMap存储
对Key or KeyTag 采用同样的hash算法，然后从TreeMap获取大于等于键hash值得节点，取最邻近节点存储；当key的hash值大于虚拟节点hash值得最大值时，存入第一个虚拟节点
sharded采用的hash算法：MD5 和 MurmurHash两种；默认采用64位的MurmurHash算法；
源码：
|
1
2
3
4
5
6
7
8
9
|
public class Sharded<R, S extends ShardInfo<R>> { public static final int DEFAULT_WEIGHT = 1; private TreeMap<Long, S> nodes; private final Hashing algo; private final Map<ShardInfo<R>, R> resources = new LinkedHashMap<ShardInfo<R>, R>(); ........................ ........................} |
这个类维护了一致性哈希后的物理机器和虚拟节点的映射关系，看一张图你会秒懂，
TreeMap<Long, S> nodes，存储的是虚拟节点和key的映射关系。有了虚拟节点，还要找到真正的存储位置。
Map<ShardInfo<R>, R> resources维护了虚拟节点和真正的存储位置的映射关系。
也是说，hash(key) -> virtual node -> real node;
jedis划分虚拟节点的逻辑代码，在Sharded类中，方法是initialize。这是在实例化对象池ShardedJedisPool过程中执行的划分虚拟节点。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
private void initialize(List<S> shards) { nodes = new TreeMap<Long, S>(); for (int i = 0; i != shards.size(); ++i) { final S shardInfo = shards.get(i); if (shardInfo.getName() == null) { for (int n = 0; n < 160 * shardInfo.getWeight(); n++) { nodes.put(this.algo.hash("SHARD-" + i + "-NODE-" + n), shardInfo); } } else { for (int n = 0; n < 160 * shardInfo.getWeight(); n++) { nodes.put(this.algo.hash(shardInfo.getName() + "*" + shardInfo.getWeight() + n), shardInfo); } } resources.put(shardInfo, shardInfo.createResource()); }} |
以上代码就是划分虚拟节点的逻辑。
那么ShardedJedis客户端是如何执行set key value呢？
通过这里可以看出还是通过Jedis客户端执行的set key value。
|
1
2
3
4
|
public String set(String key, String value) { Jedis j = getShard(key); return j.set(key, value);} |
看一下代码中大体的逻辑，首先通过key得到ShardInfo，然后通过ShardInfo得到泛型Jedis客户端。
Sharded.java
|
1
2
3
|
public R getShard(byte[] key) { return resources.get(getShardInfo(key));} |
|
1
2
3
4
5
6
7
|
public S getShardInfo(byte[] key) { SortedMap<Long, S> tail = nodes.tailMap(algo.hash(key)); if (tail.isEmpty()) { return nodes.get(nodes.firstKey()); } return tail.get(tail.firstKey());} |
Android APK 签名比对 - To build a better world ! - BlogJava
APK签名比对的实现方式
好了，通过Android签名机制的分析，我们从理论上证明了通过APK公钥的比对能判断一个APK的发布机构。并且这个发布机构是很难伪装的，我们暂时可以认为是不可伪装的。
有了理论基础后，我们就可以开始实践了。那么如何获取到APK文件的公钥信息呢？因为Android系统安装程序肯定会获取APK信息进行比对，所以我们可以通过Android源码获得一些思路和帮助。
源码中有一个隐藏的类用于APK包的解析。这个类叫PackageParser，路径为frameworks\base\core\java\android\content\pm\PackageParser.java。当我们需要获取APK包的相关信息时，可以直接使用这个类，下面代码就是一个例子函数：
2
3 PackageParser packageParser = new PackageParser(archiveFilePath);
4 DisplayMetrics metrics = new DisplayMetrics();
5 metrics.setToDefaults();
6 final File sourceFile = new File(archiveFilePath);
7 PackageParser.Package pkg = packageParser.parsePackage(
8 sourceFile, archiveFilePath, metrics, 0);
9 if (pkg == null) {
10 return null;
11 }
12
13 packageParser.collectCertificates(pkg, 0);
14
15 return PackageParser.generatePackageInfo(pkg, null, flags, 0, 0);
16 }
其中参数archiveFilePath指定APK文件路径；flags需设置PackageManager.GET_SIGNATURES位，以保证返回证书签名信息。
具体如何通过PackageParser获取签名信息在此处不做详述，具体代码请参考PackageParser中的public boolean collectCertificates(Package pkg, int flags)和private Certificate[] loadCertificates(JarFile jarFile, JarEntry je, byte[] readBuffer)方法。至于如何在Android应用开发中使用隐藏的类及方法，可以参看我的这篇文章：《Android应用开发中如何使用隐藏API》。
紧接着，我们就可以通过packageInfo.signatures来访问到APK的签名信息。还需要说明的是 Android中Signature和Java中Certificate的对应关系。它们的关系如下面代码所示：
2 for (int i=0; i<N; i++) {
3 pkg.mSignatures[i] = new Signature(
4 certs[i].getEncoded());
5 }
也就是说signature = new Signature(certificate.getEncoded()); certificate证书中包含了公钥和证书的其他基本信息。公钥不同，证书肯定互不相同。我们可以通过certificate的getPublicKey方法获取公钥信息。所以比对签名证书本质上就是比对公钥信息。
OK，获取到APK签名证书之后，就剩下比对了。这个简单，功能函数如下所示:
2 if (s1 == null) {
3 return false;
4 }
5 if (s2 == null) {
6 return false;
7 }
8 HashSet<Signature> set1 = new HashSet<Signature>();
9 for (Signature sig : s1) {
10 set1.add(sig);
11 }
12 HashSet<Signature> set2 = new HashSet<Signature>();
13 for (Signature sig : s2) {
14 set2.add(sig);
15 }
16 // Make sure s2 contains all signatures in s1.
17 if (set1.equals(set2)) {
18 return true;
19 }
20 return false;
21 }
APK签名比对的应用场景
经过以上的论述，想必大家已经明白签名比对的原理和我的实现方式了。那么什么时候什么情况适合使用签名对比来保障Android APK的软件安全呢？
个人认为主要有以下三种场景：
1、 程序自检测。在程序运行时，自我进行签名比对。比对样本可以存放在APK包内，也可存放于云端。缺点是程序被破解时，自检测功能同样可能遭到破坏，使其失效。
2、 可信赖的第三方检测。由可信赖的第三方程序负责APK的软件安全问题。对比样本由第三方收集，放在云端。这种方式适用于杀毒安全软件或者APP Market之类的软件下载市场。缺点是需要联网检测，在无网络情况下无法实现功能。（不可能把大量的签名数据放在移动设备本地）。
3、 系统限定安装。这就涉及到改Android系统了。限定仅能安装某些证书的APK。软件发布商需要向系统发布上申请证书。如果发现问题，能追踪到是哪个软件发布商的责任。适用于系统提供商或者终端产品生产商。缺点是过于封闭，不利于系统的开放性。
服务器处理能力，你估算正确过吗？ - IT旁观者 - 博客频道 - CSDN.NET
3.2 TPC-C估算公式
TPC-C是用计算机设备在每分钟内所能处理的标准事务的数量来衡量其处理能力的多少；因此，估算一个应用场景对处理能力的需求，本质上就是估算出每类业务处理事务对应的标准tpc-c事务量，然后在适当考虑冗余量。TPC-C的测算结果是每分钟的事务数，单位是tpmc。
TPC-C的通用估算公式如下：
TPC-C = ∑(每分钟业务事务量 * 标准事务量比率)/ (1 — 冗余率)。
例如：某业务系统有2类业务处理事务操作，业务事务1每分钟30000个，每个业务事务1操作相当于0.5个标准tpc-c事务；务事务2每分钟20000个，每个业务事务2操作相当于2个标准tpc-c事务；考虑30%的系统冗余。则该业务应用需要的处理能力为：
服务器处理能力(tpmc) = ((30000 X0.5) + (20000 X 2)) / (1 – 30%) = 78581。
3.3 SPEC Web估算公式
SPEC Web2005标准的衡量结果是一台Web服务器能够有效响应客户端的Web请求的最大极限个数。因此，测算的结果应该是一个Web请求数字，单位是个。
在评估应用服务器的SPEC Web2005值时，通常的方法是通过系统的在线用户，结合其在线率估算出并发用户数，在参照日常业务使用场景中可能发起的http请求来进行估算。
SPEC Web2005的参考估算公式如下：(注意：公式仅供参考，需根据项目的具体情况自行设计估算模型)
Web访问响应能力(SPEC Web2005) = (在线用户数 * 在线率 * 在线用户平均发起http请求数)/ (1 — 冗余率)。
例如：某业务系统的在线用户数为2000，在线率10%，每在线用户平均发起的http请求数为3，考虑30%的系统响应能力冗余。则负责该业务请求的Web服务器的响应能力为：
Web访问响应能力(个) = 2000 * 10% * 3 / (1 – 30%) = 857。
4 【应用实例】
下面以一个实际工程项目的应用服务器(部署Web Service中间件)的性能估算为例进行示范。
应用服务器上运行中间件产品，承担系统的各类业务逻辑组件运行计算，收敛系统用户对数据库服务器的访问请求，集中对外提供应用服务。通过分析，应用服务器性能需求在于：提供Web应用服务、业务逻辑处理。
Web应用服务方面，根据的业务预测数据，应用服务器平均在线并发用户按120估算，并发在线率20%，每用户平均发起3个http链接，考虑30%系统响应冗余能力，参照SPECweb99的评测标准，Web应用服务性能需求：Web服务器最大并发连接数=(120×20%×3)/(1 - 30%)= 103。
业务逻辑处理性能方面，主要的应用服务组件性能需求在于：集团数据监测分析、省数据监测分析、业务数据查询。据调研统计，集团数据为每分钟3585 条，省数据平均为每分钟51667条，业务信息查询请求平均为每分钟2151次；集团数据监测分析，每次业务操作约需3个标准tpcc事务，省数据监测分析，每次业务操作约需2个tpcc事务，业务信息查询，每次业务操作约需2个tpcc事务；则系统主机的处理能力需求TPCC值计算如下：
因此，应用服务器的处理能力配置不能低于196731tpmc，其Web2005配置指标不能低于103个。服务器处理性能估算实例2计算原则： 以单台服务器性能进行计算，即确保单台服务器工作的时候可以满足系统正常运行的需要；
假设每天有1万人次来窗口办理业务，每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导：
1. 假设每月前台交易数（未来5年内的设计指标）为220,000 （有些业务在月初、月末的处理量比较高，按月统计可以平衡此项差异）;2. 每日前台交易数=220000/22=10,000 ，即每日 1万笔；3. 忙时处理能力：每日交易的80%在4个小时内完成，即10000*80%/4=2000（笔/小时）4. 峰值处理能力：2000*2=4000（笔/小时），即峰值处理能力为每小时4000笔，或 67笔/分，假设业务人员同时在线为100人，即每人每分钟处理0.7笔）5. 假设每笔交易对应数据库事务数=20，基准TPC指标值对应的比例=8，cpu保留30%的处理能力冗余，计算值与公布值（最优值）的偏差经验值为4 （这几个参数估算的依据不足，更多的是经验值）
则 tpmC值为：tpmC= 67*20*8*4/(1-30%)= 61257倒算出 综合系数 = 61257/10000=6.1即数据库服务器tpmC= 每日前台交易数 * 6.1 （实际计算值应不高于该值）应用服务器的 tpmC = 数据库服务器 tpmC *50% （一般）应用服务器的 tpmC = 数据库服务器 tpmC *70% （涉及大量计算的，如社保、税务、电力、电信等）