[转]Linux的inode的理解

原文链接:
http://www.cnblogs.com/itech/archive/2012/05/15/2502284.html

一、inode是什么?
理解inode,要从文件储存说起。
文件储存在硬盘上,硬盘的最小存储单位叫做”扇区”(Sector)。每个扇区储存512字节(相当于0.5KB)。

操作系统读取硬盘的时候,不会一个个扇区地读取,这样效率太低,而是一次性连续读取多个扇区,即一次性读取一个”块”(block)。这种由多个扇区组成的”块”,是文件存取的最小单位。”块”的大小,最常见的是4KB,即连续八个 sector组成一个 block。

文件数据都储存在”块”中,那么很显然,我们还必须找到一个地方储存文件的元信息,比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做inode,中文译名为”索引节点”。

二、inode的内容
inode包含文件的元信息,具体来说有以下内容:
  * 文件的字节数
  * 文件拥有者的User ID
  * 文件的Group ID
  * 文件的读、写、执行权限
  * 文件的时间戳,共有三个:ctime指inode上一次变动的时间,mtime指文件内容上一次变动的时间,atime指文件上一次打开的时间。
  * 链接数,即有多少文件名指向这个inode
  * 文件数据block的位置

可以用stat命令,查看某个文件的inode信息:
stat example.txt

总之,除了文件名以外的所有文件信息,都存在inode之中。至于为什么没有文件名,下文会有详细解释。

三、inode的大小
inode也会消耗硬盘空间,所以硬盘格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是inode区(inode table),存放inode所包含的信息。
每个inode节点的大小,一般是128字节或256字节。inode节点的总数,在格式化时就给定,一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中,每个inode节点的大小为128字节,每1KB就设置一个inode,那么inode table的大小就会达到128MB,占整块硬盘的12.8%。

查看每个硬盘分区的inode总数和已经使用的数量,可以使用df命令。
df -i
查看每个inode节点的大小,可以用如下命令:
sudo dumpe2fs -h /dev/hda | grep “Inode size”
由于每个文件都必须有一个inode,因此有可能发生inode已经用光,但是硬盘还未存满的情况。这时,就无法在硬盘上创建新文件。

四、inode号码
每个inode都有一个号码,操作系统用inode号码来识别不同的文件。

这里值得重复一遍,Unix/Linux系统内部不使用文件名,而使用inode号码来识别文件。对于系统来说,文件名只是inode号码便于识别的别称或者绰号。表面上,用户通过文件名,打开文件。实际上,系统内部这个过程分成三步:首先,系统找到这个文件名对应的inode号码;其次,通过inode号码,获取inode信息;最后,根据inode信息,找到文件数据所在的block,读出数据。

使用ls -i命令,可以看到文件名对应的inode号码:
ls -i example.txt

五、目录文件
Unix/Linux系统中,目录(directory)也是一种文件。打开目录,实际上就是打开目录文件。

目录文件的结构非常简单,就是一系列目录项(dirent)的列表。每个目录项,由两部分组成:所包含文件的文件名,以及该文件名对应的inode号码。

ls命令只列出目录文件中的所有文件名:
ls /etc
ls -i命令列出整个目录文件,即文件名和inode号码:
ls -i /etc
如果要查看文件的详细信息,就必须根据inode号码,访问inode节点,读取信息。ls -l命令列出文件的详细信息。
ls -l /etc

六、硬链接
一般情况下,文件名和inode号码是”一一对应”关系,每个inode号码对应一个文件名。但是,Unix/Linux系统允许,多个文件名指向同一个inode号码。这意味着,可以用不同的文件名访问同样的内容;对文件内容进行修改,会影响到所有文件名;但是,删除一个文件名,不影响另一个文件名的访问。这种情况就被称为”硬链接”(hard link)。

ln命令可以创建硬链接:
ln 源文件 目标文件
运行上面这条命令以后,源文件与目标文件的inode号码相同,都指向同一个inode。inode信息中有一项叫做”链接数”,记录指向该inode的文件名总数,这时就会增加1。反过来,删除一个文件名,就会使得inode节点中的”链接数”减1。当这个值减到0,表明没有文件名指向这个inode,系统就会回收这个inode号码,以及其所对应block区域。

这里顺便说一下目录文件的”链接数”。创建目录时,默认会生成两个目录项:”.”和”..”。前者的inode号码就是当前目录的inode号码,等同于当前目录的”硬链接”;后者的inode号码就是当前目录的父目录的inode号码,等同于父目录的”硬链接”。所以,任何一个目录的”硬链接”总数,总是等于2加上它的子目录总数(含隐藏目录),这里的2是父目录对其的“硬链接”和当前目录下的”.硬链接“。

七、软链接
除了硬链接以外,还有一种特殊情况。文件A和文件B的inode号码虽然不一样,但是文件A的内容是文件B的路径。读取文件A时,系统会自动将访问者导向文件B。因此,无论打开哪一个文件,最终读取的都是文件B。这时,文件A就称为文件B的”软链接”(soft link)或者”符号链接(symbolic link)。

这意味着,文件A依赖于文件B而存在,如果删除了文件B,打开文件A就会报错:”No such file or directory”。这是软链接与硬链接最大的不同:文件A指向文件B的文件名,而不是文件B的inode号码,文件B的inode”链接数”不会因此发生变化。

ln -s命令可以创建软链接。
ln -s 源文文件或目录 目标文件或目录

八、inode的特殊作用
由于inode号码与文件名分离,这种机制导致了一些Unix/Linux系统特有的现象。
  1. 有时,文件名包含特殊字符,无法正常删除。这时,直接删除inode节点,就能起到删除文件的作用。
  2. 移动文件或重命名文件,只是改变文件名,不影响inode号码。
  3. 打开一个文件以后,系统就以inode号码来识别这个文件,不再考虑文件名。因此,通常来说,系统无法从inode号码得知文件名。
第3点使得软件更新变得简单,可以在不关闭软件的情况下进行更新,不需要重启。因为系统通过inode号码,识别运行中的文件,不通过文件名。更新的时候,新版文件以同样的文件名,生成一个新的inode,不会影响到运行中的文件。等到下一次运行这个软件的时候,文件名就自动指向新版文件,旧版文件的inode则被回收。

九 实际问题
在一台配置较低的Linux服务器(内存、硬盘比较小)的/data分区内创建文件时,系统提示磁盘空间不足,用df -h命令查看了一下磁盘使用情况,发现/data分区只使用了66%,还有12G的剩余空间,按理说不会出现这种问题。 后来用df -i查看了一下/data分区的索引节点(inode),发现已经用满(IUsed=100%),导致系统无法创建新目录和文件。

查找原因:

  /data/cache目录中存在数量非常多的小字节缓存文件,占用的Block不多,但是占用了大量的inode。

解决方案:
  1、删除/data/cache目录中的部分文件,释放出/data分区的一部分inode。
  2、用软连接将空闲分区/opt中的newcache目录连接到/data/cache,使用/opt分区的inode来缓解/data分区inode不足的问题:
  ln -s /opt/newcache /data/cache

[转]mysql死锁问题

原文链接:http://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==&mid=402122489&idx=2&sn=c9ca41d6cb075d473a2b4b001c3ffd70&scene=23&srcid=0222T6HQzXRf5vX959Mi2BHI#rd
线上某服务时不时报出如下异常(大约一天二十多次):“Deadlock found when trying to get lock;”。
Oh, My God! 是死锁问题。尽管报错不多,对性能目前看来也无太大影响,但还是需要解决,保不齐哪天成为性能瓶颈。
为了更系统的分析问题,本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。

图1 应用日志
1 死锁是怎么被发现的?
1.1 死锁成因&&检测方法
左图那两辆车造成死锁了吗?不是!右图四辆车造成死锁了吗?是!

图2 死锁描述
我们mysql用的存储引擎是innodb,从日志来看,innodb主动探知到死锁,并回滚了某一苦苦等待的事务。问题来了,innodb是怎么探知死锁的?
直观方法是在两个事务相互等待时,当一个等待时间超过设置的某一阀值时,对其中一个事务进行回滚,另一个事务就能继续执行。这种方法简单有效,在innodb中,参数innodb_lock_wait_timeout用来设置超时时间。
仅用上述方法来检测死锁太过被动,innodb还提供了wait-for graph算法来主动进行死锁检测,每当加锁请求无法立即满足需要并进入等待时,wait-for graph算法都会被触发。
1.2 wait-for graph原理
我们怎么知道上图中四辆车是死锁的?他们相互等待对方的资源,而且形成环路!我们将每辆车看为一个节点,当节点1需要等待节点2的资源时,就生成一条有向边指向节点2,最后形成一个有向图。我们只要检测这个有向图是否出现环路即可,出现环路就是死锁!这就是wait-for graph算法。
图3 wait for graph
innodb将各个事务看为一个个节点,资源就是各个事务占用的锁,当事务1需要等待事务2的锁时,就生成一条有向边从1指向2,最后行成一个有向图。
1.2 innodb隔离级别、索引与锁
死锁检测是死锁发生时innodb给我们的救命稻草,我们需要它,但我们更需要的是避免死锁发生的能力,如何尽可能避免?这需要了解innodb中的锁。
1.2.1 锁与索引的关系
假设我们有一张消息表(msg),里面有3个字段。假设id是主键,token是非唯一索引,message没有索引。
id: bigint token: varchar(30) message: varchar(4096)
innodb对于主键使用了聚簇索引,这是一种数据存储方式,表数据是和主键一起存储,主键索引的叶结点存储行数据。对于普通索引,其叶子节点存储的是主键值。
图4 聚簇索引和二级索引
下面分析下索引和锁的关系。
1)delete from msg where id=2;
由于id是主键,因此直接锁住整行记录即可。
图5
2)delete from msg where token=’ cvs’;
由于token是二级索引,因此首先锁住二级索引(两行),接着会锁住相应主键所对应的记录;
图6
3)delete from msg where message=订单号是多少’;
message没有索引,所以走的是全表扫描过滤。这时表上的各个记录都将添加上X锁。
图7
1.2.2 锁与隔离级别的关系
大学数据库原理都学过,为了保证并发操作数据的正确性,数据库都会有事务隔离级别的概念:1)未提交读(Read uncommitted);2)已提交读(Read committed(RC));3)可重复读(Repeatable read(RR));4)可串行化(Serializable)。我们较常使用的是RC和RR。
提交读(RC):只能读取到已经提交的数据。
可重复读(RR):在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。
我们在1.2.1节谈论的其实是RC隔离级别下的锁,它可以防止不同事务版本的数据修改提交时造成数据冲突的情况,但当别的事务插入数据时可能会出现问题。
如下图所示,事务A在第一次查询时得到1条记录,在第二次执行相同查询时却得到两条记录。从事务A角度上看是见鬼了!这就是幻读,RC级别下尽管加了行锁,但还是避免不了幻读。
图8
innodb的RR隔离级别可以避免幻读发生,怎么实现?当然需要借助于锁了!
为了解决幻读问题,innodb引入了gap锁。
在事务A执行:update msg set message=‘订单’ where token=‘asd’;
innodb首先会和RC级别一样,给索引上的记录添加上X锁,此外,还在非唯一索引’asd’与相邻两个索引的区间加上锁。
这样,当事务B在执行insert into msg values (null,‘asd’,’hello’); commit;时,会首先检查这个区间是否被锁上,如果被锁上,则不能立即执行,需要等待该gap锁被释放。这样就能避免幻读问题。
图9
推荐一篇好文,可以深入理解锁的原理:http://hedengcheng.com/?p=771#_Toc374698322
3 死锁成因
了解了innodb锁的基本原理后,下面分析下死锁的成因。如前面所说,死锁一般是事务相互等待对方资源,最后形成环路造成的。下面简单讲下造成相互等待最后形成环路的例子。
3.1不同表相同记录行锁冲突
这种情况很好理解,事务A和事务B操作两张表,但出现循环等待锁情况。

图10
3.2相同表记录行锁冲突
这种情况比较常见,之前遇到两个job在执行数据批量更新时,jobA处理的的id列表为[1,2,3,4],而job处理的id列表为[8,9,10,4,2],这样就造成了死锁。

图11
3.3不同索引锁冲突
这种情况比较隐晦,事务A在执行时,除了在二级索引加锁外,还会在聚簇索引上加锁,在聚簇索引上加锁的顺序是[1,4,2,3,5],而事务B执行时,只在聚簇索引上加锁,加锁顺序是[1,2,3,4,5],这样就造成了死锁的可能性。
图12
3.4 gap锁冲突
innodb在RR级别下,如下的情况也会产生死锁,比较隐晦。不清楚的同学可以自行根据上节的gap锁原理分析下。
图13
4 如何尽可能避免死锁
1)以固定的顺序访问表和行。比如对第2节两个job批量更新的情形,简单方法是对id列表先排序,后执行,这样就避免了交叉等待锁的情形;又比如对于3.1节的情形,将两个事务的sql顺序调整为一致,也能避免死锁。
2)大事务拆小。大事务更倾向于死锁,如果业务允许,将大事务拆小。
3)在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率。
4)降低隔离级别。如果业务允许,将隔离级别调低也是较好的选择,比如将隔离级别从RR调整为RC,可以避免掉很多因为gap锁造成的死锁。
5)为表添加合理的索引。可以看到如果不走索引将会为表的每一行记录添加上锁,死锁的概率大大增大。
5 如何定位死锁成因
下面以本文开头的死锁案例为例,讲下如何排查死锁成因。
1)通过应用业务日志定位到问题代码,找到相应的事务对应的sql;
因为死锁被检测到后会回滚,这些信息都会以异常反应在应用的业务日志中,通过这些日志我们可以定位到相应的代码,并把事务的sql给梳理出来。
start tran
1 deleteHeartCheckDOByToken
2 updateSessionUser

commit
此外,我们根据日志回滚的信息发现在检测出死锁时这个事务被回滚。
2)确定数据库隔离级别。
执行select @@global.tx_isolation,可以确定数据库的隔离级别,我们数据库的隔离级别是RC,这样可以很大概率排除gap锁造成死锁的嫌疑;
3)找DBA执行下show InnoDB STATUS看看最近死锁的日志。
这个步骤非常关键。通过DBA的帮忙,我们可以有更为详细的死锁信息。通过此详细日志一看就能发现,与之前事务相冲突的事务结构如下:
start tran
1 updateSessionUser
2 deleteHeartCheckDOByToken

commit
  这不就是图10描述的死锁嘛!

[转]mysql锁表和解锁语句分享

原文地址:http://www.jb51.net/article/28287.htm
对于MySQL来说,有三种锁的级别:页级、表级、行级
页级的典型代表引擎为BDB。
表级的典型代表引擎为MyISAM,MEMORY以及很久以前的ISAM。
行级的典型代表引擎为INNODB。
-我们实际应用中用的最多的就是行锁。
行级锁的优点如下:
1)、当很多连接分别进行不同的查询时减小LOCK状态。
2)、如果出现异常,可以减少数据的丢失。因为一次可以只回滚一行或者几行少量的数据。
行级锁的缺点如下:
1)、比页级锁和表级锁要占用更多的内存。
2)、进行查询时比页级锁和表级锁需要的I/O要多,所以我们经常把行级锁用在写操作而不是读操作。
3)、容易出现死锁。
对于写锁定如下:
1)、如果表没有加锁,那么对其加写锁定。
2)、否则,那么把请求放入写锁队列中。
对于读锁定如下:
1)、如果表没有加写锁,那么加一个读锁。
2)、否则,那么把请求放到读锁队列中。
当然我们可以分别用low_priority 以及high_priority在写和读操作上来改变这些行为。

如果想要在一个表上做大量的 INSERT 和 SELECT 操作,但是并行的插入却不可能时,可以将记录插入到临时表中,然后定期将临时表中的数据更新到实际的表里。可以用以下命令实现:

mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
mysql> INSERT INTO real_table SELECT * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;
InnoDB 使用行级锁,BDB 使用页级锁。对于 InnoDB 和 BDB 存储引擎来说,是可能产生死锁的。这是因为 InnoDB 会自动捕获行锁,BDB 会在执行 SQL 语句时捕获页锁的,而不是在事务的开始就这么做。
行级锁的优点有:

在很多线程请求不同记录时减少冲突锁。
事务回滚时减少改变数据。
使长时间对单独的一行记录加锁成为可能。
行级锁的缺点有:

比页级锁和表级锁消耗更多的内存。
当在大量表中使用时,比页级锁和表级锁更慢,因为他需要请求更多的所资源。
当需要频繁对大部分数据做 GROUP BY 操作或者需要频繁扫描整个表时,就明显的比其它锁更糟糕。
使用更高层的锁的话,就能更方便的支持各种不同的类型应用程序,因为这种锁的开销比行级锁小多了。
表级锁在下列几种情况下比页级锁和行级锁更优越:

很多操作都是读表。
在严格条件的索引上读取和更新,当更新或者删除可以用单独的索引来读取得到时:

UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;
DELETE FROM tbl_name WHERE unique_key_col=key_value;
SELECT 和 INSERT 语句并发的执行,但是只有很少的 UPDATE 和 DELETE 语句。
很多的扫描表和对全表的 GROUP BY 操作,但是没有任何写表。
表级锁和行级锁或页级锁之间的不同之处还在于:
将同时有一个写和多个读的地方做版本(例如在MySQL中的并发插入)。也就是说,数据库/表支持根据开始访问数据时间点的不同支持各种不同的试图。其它名有:时间行程,写复制,或者是按需复制。
复制代码 代码如下:

//执行SQL语句 锁掉stat_num表
$sql = “LOCK TABLES stat_num WRITE”; //表的WRITE锁定,阻塞其他所有mysql查询进程
$DatabaseHandler->exeCute($sql);
//执行更新或写入操作
$sql = “UPDATE stat_num SET `correct_num`=`correct_num`+1 WHERE stat_date='{$cur_date}'”;
$DatabaseHandler->exeCute($sql);
//当前请求的所有写操作做完后,执行解锁sql语句
$sql = “UNLOCK TABLES”;
$DatabaseHandler->exeCute($sql);

[转]Mongodb与Redis应用指标对比

MongoDB和Redis都是NoSQL,采用结构型数据存储。二者在使用场景中,存在一定的区别,这也主要由于
二者在内存映射的处理过程,持久化的处理方法不同。MongoDB建议集群部署,更多的考虑到集群方案,Redis
更偏重于进程顺序写入,虽然支持集群,也仅限于主-从模式。

指标 MongoDB(v2.4.9) Redis(v2.4.17) 比较说明
实现语言 C++ C/C++ –
协议 BSON、自定义二进制 类Telnet –
性能 依赖内存,TPS较高 依赖内存,TPS非常高 Redis优于MongoDB
可操作性 丰富的数据表达、索引;最类似于关系数据库,支持丰富的查询语言 数据丰富,较少的IO MongoDB优于Redis
内存及存储 适合大数据量存储,依赖系统虚拟内存管理,采用镜像文件存储;内存占有率比较高,官方建议独立部署在64位系统(32位有最大2.5G文件限制,64位没有改限制) Redis2.0后增加虚拟内存特性,突破物理内存限制;数据可以设置时效性,类似于memcache 不同的应用角度看,各有优势
可用性 支持master-slave,replicaset(内部采用paxos选举算法,自动故障恢复),auto sharding机制,对客户端屏蔽了故障转移和切分机制 依赖客户端来实现分布式读写;主从复制时,每次从节点重新连接主节点都要依赖整个快照,无增量复制;不支持自动sharding,需要依赖程序设定一致hash机制 MongoDB优于Redis;单点问题上,MongoDB应用简单,相对用户透明,Redis比较复杂,需要客户端主动解决。(MongoDB一般会使用replica sets和sharding功能结合,replica sets侧重高可用性及高可靠性,而sharding侧重于性能、易扩展)
可靠性 从1.8版本后,采用binlog方式(MySQL同样采用该方式)支持持久化,增加可靠性 依赖快照进行持久化;AOF增强可靠性;增强可靠性的同时,影响访问性能 MongoDB优于Redis
一致性 不支持事物,靠客户端自身保证 支持事物,比较弱,仅能保证事物中的操作按顺序执行 Redis优于MongoDB
数据分析 内置数据分析功能(mapreduce) 不支持 MongoDB优于Redis
应用场景 海量数据的访问效率提升 较小数据量的性能及运算 MongoDB优于Redis

[转]微信红包的随机算法

【原文】http://gold.xitu.io/entry/56bd3dd16be3ffc0224a4f30
有人问过微信的人,大致是这样:
先上代码:

public static double getRandomMoney(LeftMoneyPackage _leftMoneyPackage) {
// remainSize 剩余的红包数量
// remainMoney 剩余的钱
if (_leftMoneyPackage.remainSize == 1) {
_leftMoneyPackage.remainSize–;
return (double) Math.round(_leftMoneyPackage.remainMoney * 100) / 100;
}
Random r = new Random();
double min = 0.01; //
double max = _leftMoneyPackage.remainMoney / _leftMoneyPackage.remainSize * 2;
double money = r.nextDouble() * max;
money = money min ? 0.01: money;
money = Math.floor(money * 100) / 100;
_leftMoneyPackage.remainSize–;
_leftMoneyPackage.remainMoney -= money;
return money;
}

再说结论:
先抢后抢拿到红包的大小的期望是大致相等的,所以还是先下手抢吧
后抢的人方差大(依赖前面人抢的多少),波动较大,有较大几率拿到“手气最佳”

祝大家抢红包快乐哦~
测试数据。
测试结果测试随机红包

以上面的初始化数据(30人抢500块),执行了两次,结果如下:

// 第一次
15.69 21.18 24.11 30.85 0.74 20.85 2.96 13.43 11.12 24.87 1.86 19.62 5.97 29.33 3.05 26.94 18.69 34.47 9.4 29.83 5.17 24.67 17.09 29.96 6.77 5.79 0.34 23.89 40.44 0.92

// 第二次
10.44 18.01 17.01 21.07 11.87 4.78 30.14 32.05 16.68 20.34 12.94 27.98 9.31 17.97 12.93 28.75 12.1 12.77 7.54 10.87 4.16 25.36 26.89 5.73 11.59 23.91 17.77 15.85 23.42 9.77
对应图表如下:

还有一张:

多次均值
200次

2000次

可以看到,这个算法可以让大家抢到的红包面额在概率上是大致均匀的。

转一下原文

微信红包的架构设计简介
@来源于QCon某高可用架构群整理,整理朱玉华。

背景:有某个朋友在朋友圈咨询微信红包的架构,于是乎有了下面的文字(有误请提出,谢谢)

概况:2014年微信红包使用数据库硬抗整个流量,2015年使用cache抗流量。

1. 微信的金额什么时候算?

答:微信金额是拆的时候实时算出来,不是预先分配的,采用的是纯内存计算,不需要预算空间存储。
采取实时计算金额的考虑:预算需要占存储,实时效率很高,预算才效率低。

2. 实时性:为什么明明抢到红包,点开后发现没有?

答:2014年的红包一点开就知道金额,分两次操作,先抢到金额,然后再转账。
2015年的红包的拆和抢是分离的,需要点两次,因此会出现抢到红包了,但点开后告知红包已经被领完的状况。进入到第一个页面不代表抢到,只表示当时红包还有。

3. 分配:红包里的金额怎么算?为什么出现各个红包金额相差很大?

答:随机,额度在0.01和(剩余平均值*2)之间。
例如:发100块钱,总共10个红包,那么平均值是10块钱一个,那么发出来的红包的额度在0.01元~20元之间波动。
当前面3个红包总共被领了40块钱时,剩下60块钱,总共7个红包,那么这7个红包的额度在:0.01~(60/7*2)=17.14之间。
注意:这里的算法是每被抢一个后,剩下的会再次执行上面的这样的算法(Tim老师也觉得上述算法太复杂,不知基于什么样的考虑)。

这样算下去,会超过最开始的全部金额,因此到了最后面如果不够这么算,那么会采取如下算法:保证剩余用户能拿到最低1分钱即可。

如果前面的人手气不好,那么后面的余额越多,红包额度也就越多,因此实际概率一样的。

4. 红包的设计

答:微信从财付通拉取金额数据过来,生成个数/红包类型/金额放到redis集群里,app端将红包ID的请求放入请求队列中,如果发现超过红包的个数,直接返回。根据红包的裸祭处理成功得到令牌请求,则由财付通进行一致性调用,通过像比特币一样,两边保存交易记录,交易后交给第三方服务审计,如果交易过程中出现不一致就强制回归。

5. 发性处理:红包如何计算被抢完?

答:cache会抵抗无效请求,将无效的请求过滤掉,实际进入到后台的量不大。cache记录红包个数,原子操作进行个数递减,到0表示被抢光。财付通按照20万笔每秒入账准备,但实际还不到8万每秒。

6. 通如何保持8w每秒的写入?

答:多主sharding,水平扩展机器。

7. 据容量多少?

答:一个红包只占一条记录,有效期只有几天,因此不需要太多空间。

8. 询红包分配,压力大不?

答:抢到红包的人数和红包都在一条cache记录上,没有太大的查询压力。

9. 一个红包一个队列?

答:没有队列,一个红包一条数据,数据上有一个计数器字段。

10.有没有从数据上证明每个红包的概率是不是均等?

答:不是绝对均等,就是一个简单的拍脑袋算法。

11.拍脑袋算法,会不会出现两个最佳?

答:会出现金额一样的,但是手气最佳只有一个,先抢到的那个最佳。

12. 每领一个红包就更新数据么?

答:每抢到一个红包,就cas更新剩余金额和红包个数。

13.红包如何入库入账?

数据库会累加已经领取的个数与金额,插入一条领取记录。入账则是后台异步操作。

14. 入帐出错怎么办?比如红包个数没了,但余额还有?

答:最后会有一个take all操作。另外还有一个对账来保障。
附录:附上自己的PHP代码

class Money {
    
    public $leftNum;
    public $leftMoney;
    public $allocation;
    
    public function __construct($money, $num) {
        
        if($num * 0.01 > $money) {
            echo "money and num wrong";
            die();
        }
        
        $this->leftNum   = $num;
        $this->leftMoney = $money;
    }
    
    public function getRandomMoney() {
            
        if($this->leftNum == 1){
            $this->allocation[] = $this->leftMoney;
            $this->leftNum --;
            return $this->allocation;
        }
        
        $min = 0.01;
        $max = round($this->leftMoney*100*2/$this->leftNum) / 100;
        $money = mt_rand($min * 100, ($max-0.01)* 100)/100;
        $this->allocation[] = $money;
        $this->leftMoney   -= $money;
        $this->leftNum --;
        return $this->getRandomMoney(); 
    }
}

一般的JS游戏作弊方法

手机端JS游戏可以通过Fiddler抓包,然后修改参数提交的服务器接口进行分数修改
Fiddler可以通过Rules=>Automatics BreakPoints=>Before Requests,在每次请求前增加断点,这样就可以修改请求的参数。一般的url get或者post请求会带上score这个参数,直接修改数值即可。

另外一些游戏添加了token,cookie和score计算一个加密的分数,这个不好随意更改,但是但凡前端的数据或者加密算法其实都是可见的,一般通过混淆JS代码可以让攻击者不好读。但是chrome断点和分步调试可以一步一步找到调用顺序,或者上传分数接口函数。在控制台直接调用它JS提供的加密方式就可以直接计算出加密数据。也就顺利的提交的分数。
所以一般的FLASH小游戏要想做到防止直接请求接口作弊还是需要增加一些方法的。

利用smarty escape函数防止XSS攻击

XSS攻击常见手段就是在输入的内容框中添加脚本来执行操作,比如获取用户的cookie,提交到自己的网站中。
Smarty模板中有escape函数,http://fising.cn/docs/Smarty_3_Manual_zh_cn/language.modifier.escape.html
它和JS中的escape()函数很像,但是可以选择不同的参数。
默认的参数html只转换 & ” ‘ < > *,可以有效的防止script脚本注入。
<{$test|escape}>
官方手册给的例子是:
<{$test|escape:"html"}> escapes & ” ‘ < >
<{$test|escape:"htmlall"} {* escapes ALL html entities *} <{$test|escape:"url"} <{$test|escape:"quotes"} “>$test|escape:”hexentity”}
这种用法虽然可以屏蔽HTML但是每个变量后面都带带上|escape,给写程序带来麻烦。
下面介绍下本人开发中所使用的方法,也算有点偏门但挺实用
SMARTY 有个 default_modifiers 变量 官方解释是默认修正器变量
我们可以利用它来修正
在显示页面前先执行
$smarty->default_modifiers = array(‘$’ => ‘escape:”html”‘);
这样所有以$开头的SMARTY变量都被处理了
同时我们也可以
$smarty->default_modifiers = array(‘$’ => ‘escape:”html”‘,’foreach’=> ‘smarty:”nodefaults”‘,’section’=> ‘smarty:”nodefaults”‘);
这么一来页面上$开头的变量都被转义,那有些变量我们需要html怎么办呢
<{$test|smarty:nodefaults}>
smarty:nodefaults可以让变量免除于默认修正器,这样就能使用html显示了

[转]图解SSL/TLS协议

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

一、SSL协议的握手过程
开始加密通信之前,客户端和服务器首先必须建立连接和交换参数,这个过程叫做握手(handshake)。
假定客户端叫做爱丽丝,服务器叫做鲍勃,整个握手过程可以用下图说明(点击看大图)。

握手阶段分成五步。
第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。
第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。
第三步,爱丽丝确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给鲍勃。
第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。
第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成”对话密钥”(session key),用来加密接下来的整个对话过程。
上面的五步,画成一张图,就是下面这样。

二、私钥的作用
握手阶段有三点需要注意。
(1)生成对话密钥一共需要三个随机数。
(2)握手之后的对话使用”对话密钥”加密(对称加密),服务器的公钥和私钥只用于加密和解密”对话密钥”(非对称加密),无其他作用。
(3)服务器公钥放在服务器的数字证书之中。
从上面第二点可知,整个对话过程中(握手阶段和其后的对话),服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。
某些客户(比如银行)想要使用外部CDN,加快自家网站的访问速度,但是出于安全考虑,不能把私钥交给CDN服务商。这时,完全可以把私钥留在自家服务器,只用来解密对话密钥,其他步骤都让CDN服务商去完成。

上图中,银行的服务器只参与第四步,后面的对话都不再会用到私钥了。
三、DH算法的握手阶段
整个握手阶段都不加密(也没法加密),都是明文的。因此,如果有人窃听通信,他可以知道双方选择的加密方法,以及三个随机数中的两个。整个通话的安全,只取决于第三个随机数(Premaster secret)能不能被破解。
虽然理论上,只要服务器的公钥足够长(比如2048位),那么Premaster secret可以保证不被破解。但是为了足够安全,我们可以考虑把握手阶段的算法从默认的RSA算法,改为 Diffie-Hellman算法(简称DH算法)。
采用DH算法后,Premaster secret不需要传递,双方只要交换各自的参数,就可以算出这个随机数。

上图中,第三步和第四步由传递Premaster secret变成了传递DH算法所需的参数,然后双方各自算出Premaster secret。这样就提高了安全性。
四、session的恢复
握手阶段用来建立SSL连接。如果出于某种原因,对话中断,就需要重新握手。
这时有两种方法可以恢复原来的session:一种叫做session ID,另一种叫做session ticket。
session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的”对话密钥”,而不必重新生成一把。

上图中,客户端给出session ID,服务器确认该编号存在,双方就不再进行握手阶段剩余的步骤,而直接用已有的对话密钥进行加密通信。
session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。

上图中,客户端不再发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的,只有服务器才能解密,其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket以后,解密后就不必重新生成对话密钥了。

浮点数计算的问题

首先鸟哥的博客说明过这个问题:
http://www.laruence.com/2013/03/26/2884.html
不过, 我当时遗漏了一点, 也就是对于如下的这个常见问题的回答:

	<?php
	    $f = 0.58;
	    var_dump(intval($f * 100)); //为啥输出57
	?>

为啥输出是57啊? PHP的bug么?
我相信有很多的同学有过这样的疑问, 因为光问我类似问题的人就很多, 更不用说bugs.php.net上经常有人问…
要搞明白这个原因, 首先我们要知道浮点数的表示(IEEE 754):
浮点数, 以64位的长度(双精度)为例, 会采用1位符号位(E), 11指数位(Q), 52位尾数(M)表示(一共64位).
符号位:最高位表示数据的正负,0表示正数,1表示负数。
指数位:表示数据以2为底的幂,指数采用偏移码表示
尾数:表示数据小数点后的有效数字.
这里的关键点就在于, 小数在二进制的表示, 关于小数如何用二进制表示, 大家可以百度一下, 我这里就不再赘述, 我们关键的要了解, 0.58 对于二进制表示来说, 是无限长的值(下面的数字省掉了隐含的1)..
1. 0.58的二进制表示基本上(52位)是: 0010100011110101110000101000111101011100001010001111
2. 0.57的二进制表示基本上(52位)是: 0010001111010111000010100011110101110000101000111101
而两者的二进制, 如果只是通过这52位计算的话,分别是:
1. 0.58 -> 0.57999999999999996
2. 0.57 -> 0.56999999999999995
至于0.58 * 100的具体浮点数乘法, 我们不考虑那么细, 有兴趣的可以看(Floating point), 我们就模糊的以心算来看… 0.58 * 100 = 57.999999999
那你intval一下, 自然就是57了….
可见, 这个问题的关键点就是: “你看似有穷的小数, 在计算机的二进制表示里却是无穷的”
所以这样的判断方法

$a = 0.2+0.7;
$b = 0.9;
var_dump($a == $b);

结果是false,根本不可靠
打印精度结果

$a = 0.2+0.7;
$b = 0.9;
printf("%0.20f", $a);
echo '<br />';
printf("%0.20f", $b);

结果是
0.89999999999999991118
0.90000000000000002220
显然在这里,实际上作为浮点型数据,其精度已经损失了一部分,达不到完全精确。所以永远不要相信浮点数结果精确到了最后一位,也永远不要比较两个浮点数是否相等。需要说明的是,这不是PHP的问题,而是计算机内部处理浮点数的问题!在 C、JAVA 等语言中也会遇到同样的问题。
所以要比较两个浮点数,需要将其控制在我们需要的精度范围内再行比较,因此使用 bcadd() 函数来对浮点数想加并进行精度转换(为字符串):
http://php.net/manual/zh/function.bcadd.php

[转]MyCat:开源分布式数据库中间件

原文链接:http://www.csdn.net/article/2015-07-16/2825228

为什么需要MyCat?
虽然云计算时代,传统数据库存在着先天性的弊端,但是NoSQL数据库又无法将其替代。如果传统数据易于扩展,可切分,就可以避免单机(单库)的性能缺陷。
MyCat的目标就是:低成本地将现有的单机数据库和应用平滑迁移到“云”端,解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。2014年MyCat首次在上海的《中华架构师》大会上对外宣讲引发围观,更多的人参与进来,随后越来越多的项目采用了MyCat。
MyCat截至到2015年4月,保守估计已经有超过60个项目在使用,主要应用在电信领域、互联网项目,大部分是交易和管理系统,少量是信息系统。比较大的系统中,数据规模单表单月30亿。
MyCat是什么?
从定义和分类来看,它是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理,用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。
MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。而在最终用户看来,无论是那种存储方式,在MyCat里,都是一个传统的数据库表,支持标准的SQL语句进行数据的操作,这样一来,对前端业务系统来说,可以大幅降低开发难度,提升开发速度

图1 MyCat架构设计图
MyCat解决了哪些问题
1. 连接过多问题,可以通过MyCat统一管理所有的数据源,后端数据库集群对前端应用程序透明。使用MyCat之前系统结构如图2。

图2 MyCat早前系统架构
MyCat引入连接复用解决多应用竞争问题,通过MyCat改造后,如图3所示。

图3 改造后的MyCat
2. 独创的ER关系分片,解决E-R分片难处理问题,存在关联关系的父子表在数据插入的过程中,子表会被MyCat路由到其相关父表记录的节点上,从而父子表的Join查询可以下推到各个数据库节点上完成,这是最高效的跨节点Join处理技术,也是MyCat首创。

图4 独创的ER关系分片,是MyCat首创
3. 采用全局分片技术,每个节点同时并发插入和更新数据,每个节点都可以读取数据,提升读性能的同时,也解决跨节点Join的效率。

图5 采用全局分片技术
4. 通过人工智能的catlet支持跨分片复杂SQL实现以及存储过程支持等。使用方式主要通过MyCat注释的方式来执行,如下:
(1)跨分片联合查询注解支持:
/*!MyCat:catlet=demo.catlets.ShareJoin / select bu. ,sg.* from base_user bu,sam_glucose sg where bu.id_=sg.user_id;
注:sam_glucose是跨分片表。
(2)存储过程注解支持:
/*!MyCat: sql=select * from base_user where id_=1;*/ CALL proc_test();
注:目前执行存储过程通过MyCat注解的方式执行,注意需要把存储过程中的sql写到注解中。
(3)批量插入与ID自增长结合的支持:
/*!MyCat:catlet=demo.catlets.BatchInsertSequence */ insert into sam_test(name_) values(‘t1’),(‘t2’);
注:此方式不需要在sql语句中显示的设置主键字段,程序在后台根据primaryKey配置的主键列,自动生成主键的sequence值并替换原sql中相关的列和值;
(4)获取批量sequence值的支持:
/*!MyCat:catlet=demo.catlets.BatchGetSequence */SELECT MyCat_get_seq(‘MyCat_TEST’,100);
注:此方法表示获取MyCat_TEST表的100个sequence值,例如当前MyCat_TEST表的最大sequence值为5000,则通过此方式返回的是5001,同时更新数据库中的MyCat_TEST表的最大sequence值为5100。
(5)更好地支持数据库读写分离与高可用性,MyCat支持基于MySQL主从复制状态的高级读写分离控制机制(比如Slave_behind_master <100则开启),而一旦检测到主从同步出错或者延时超过发展,则自动排除readHost,防止程序读到很久的旧数据。 图6 Mycat支持基于MySQL主从复制状态的高级读写分离控制机制 MyCat技术原理 MyCat技术原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。 图7 Orders被分为三个分片datanode 如图7所示,Orders表被分为三个分片datanode(简称dn),这三个分片是分布在两台MySQL Server上(DataHost),即datanode=database@datahost方式,因此你可以用一台到N台服务器来分片,分片规则为(sharding rule)典型的字符串枚举分片规则,一个规则的定义是分片字段(sharding column)+分片函数(rule function),这里的分片字段为prov而分片函数为字符串枚举方式。当MyCat收到一个SQL时,会先解析这个SQL,查找涉及到的表,然后看此表的定义,如果有分片规则,则获取到SQL里分片字段的值,并匹配分片函数,得到该SQL对应的分片列表,然后将SQL发往这些分片去执行,最后收集和处理所有分片返回的结果数据,并输出到客户端。以select * from Orders where prov=?语句为例,查到prov=wuhan,按照分片函数,wuhan返回dn1,于是SQL就发给了MySQL1,去取DB1上的查询结果,并返回给用户。如果上述SQL改为select * from Orders where prov in (‘wuhan’,‘beijing’),那么,SQL就会发给MySQL1与MySQL2去执行,然后结果集合并后输出给用户。但通常业务中我们的SQL会有Order By以及Limit翻页语法,此时就涉及到结果集在MyCat端的二次处理,这部分的代码也比较复杂,而最复杂的则属两个表的Jion问题,为此,MyCat提出了创新性的ER分片、全局表、HBT(Human Brain Tech)人工智能的Catlet等。 MyCat下一步规划 强化分布式数据库中间件的面的功能,使之具备丰富的插件、强大的数据库智能优化功能、全面的系统监控能力、以及方便的数据运维工具,实现在线数据扩容、迁移等高级功能。 进一步挺进大数据计算领域,深度结合Spark Stream和Storm等分布式实时流引擎,能够完成快速的巨表关联、排序、分组聚合等OLAP方向的能力,并集成一些热门常用的实时分析算法,让工程师以及DBA们更容易用MyCat实现一些高级数据分析处理功能。