Redis应用场景

1.  MySql+Memcached架构的问题

Memcached采用客户端服务器的架构,客户端和服务器端的通讯使用自定义的协议标准,只要满足协议格式要求,客户端Library可以用任何语言实现。

Memcached服务器使用基于Slab的内存管理方式,有利于减少内存碎片和频繁分配销毁内存所带来的开销。各个Slab按需动态分配一个page的内存(和4Kpage的概念不同,这里默认page1M),page内部按照不同slab class的尺寸再划分为内存chunk供服务器存储KV键值对使用(slab机制相当于内存池机制, 实现从操作系统分配一大块内存, 然后 memcached 自己管理这块内存, 负责分配与回收。)

关于memcached的内存分配机制:Memcached 内存分配机制介绍

实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:

1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间。

2.Memcached与MySQL数据库数据一致性问题。

3.Memcached数据命中率低或down机,大量访问直接穿透到DB,MySQL无法支撑。

4.跨机房cache同步问题。

关于memcached问题:Memcache存储大数据的问题

众多NoSQL百花齐放,如何选择

最近几年,业界不断涌现出很多各种各样的NoSQL产品,那么如何才能正确地使用好这些产品,最大化地发挥其长处,是我们需要深入研究和思考的问题,实际归根结底最重要的是了解这些产品的定位,并且了解到每款产品的tradeoffs,在实际应用中做到扬长避短,总体上这些NoSQL主要用于解决以下几种问题

1.少量数据存储,高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是Redis最主要的适用场景。

2.海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。

3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过gossip方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log,然后定期compat归并到磁盘上,将随机写优化为顺序写,提高写入性能。

4.Schema free,auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的,直接存储json格式数据,并且支持auto-sharding等功能,比如mongodb。

面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。

Redis最适合所有数据in-momory的场景,虽然Redis也提供持久化功能,但实际更多的是一个disk-backed的功能,跟传统意义上的持久化有比较大的差别,那么可能大家就会有疑问,似乎Redis更像一个加强版的Memcached,那么何时使用Memcached,何时使用Redis呢?

memcache和redis的比较:

  • 性能方面:没有必要过多的关心性能,因为二者的性能都已经足够高了。由于Redis只使用单核,而Memcached可以使用多核,所以在比较上,平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中,Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化,但是比起Memcached,还是稍有逊色。说了这么多,结论是,无论你使用哪一个,每秒处理请求的次数都不会成为瓶颈。(比如瓶颈可能会在网卡)
  • 内存使用效率:使用简单的key-value存储的话,Memcached的内存利用率更高,而如果Redis采用hash结构来做key-value存储,由于其组合式的压缩,其内存利用率会高于Memcached。当然,这和你的应用场景和数据特性有关。
  • 数据持久化:如果你对数据持久化和数据同步有所要求,那么推荐你选择Redis,因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失,选择Redis也是明智的。
  • 数据结构:当然,最后还得说到你的具体应用需求。Redis相比Memcached来说,拥有更多的数据结构和并支持更丰富的数据操作,通常在Memcached里,你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中,这些复杂的操作通常和一般的GET/SET一样高效。所以,如果你需要缓存能够支持更复杂的结构和操作,那么Redis会是不错的选择。
  • 网络IO模型方面:Memcached是多线程,分为监听线程、worker线程,引入锁,带来了性能损耗。Redis使用单线程的IO复用模型,将速度优势发挥到最大,也提供了较简单的计算功能
  • 内存管理方面:Memcached使用预分配的内存池的方式,带来一定程度的空间浪费 并且在内存仍然有很大空间时,新的数据也可能会被剔除,而Redis使用现场申请内存的方式来存储数据,不会剔除任何非临时数据 Redis更适合作为存储而不是cache
  • 数据的一致性方面:Memcached提供了cas命令来保证.而Redis提供了事务的功能,可以保证一串 命令的原子性,中间不会被任何操作打断

如果简单地比较Redis与Memcached的区别,大多数都会得到以下观点:

1 、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。

2 、Redis支持数据的备份,即master-slave模式的数据备份。

3 、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。

4、Redis可以实现主从复制,实现故障恢复。

5、Redis的Sharding技术: 很容易将数据分布到多个Redis实例中

2.  Redis常用数据类型

Redis最为常用的数据类型主要有以下:

  • String
  • Hash
  • List
  • Set
  • Sorted set
  • pub/sub
  • Transactions

在具体描述这几种数据类型之前,我们先通过一张图了解下Redis内部内存管理中是如何描述这些不同数据类型的:

         首先Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示:

type代表一个value对象具体是何种数据类型,

encoding是不同数据类型在redis内部的存储方式,

比如:type=string代表value存储的是一个普通字符串,那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的,当然前提是这个字符串本身可以用数值表示,比如:”123″ “456”这样的字符串。

这里需要特殊说明一下vm字段,只有打开了Redis的虚拟内存功能,此字段才会真正的分配内存,该功能默认是关闭状态的,该功能会在后面具体描述。通过上图我们可以发现Redis使用redisObject来表示所有的key/value数据是比较浪费内存的,当然这些内存管理成本的付出主要也是为了给Redis不同数据类型提供一个统一的管理接口,实际作者也提供了多种方法帮助我们尽量节省内存使用,我们随后会具体讨论。

3.  各种数据类型应用和实现方式

下面我们先来逐一的分析下这7种数据类型的使用和内部实现方式:

  • String:
Strings 数据结构是简单的key-value类型,value其实不仅是String,也可以是数字.

常用命令:  set,get,decr,incr,mget 等。

应用场景:String是最常用的一种数据类型,普通的key/ value 存储都可以归为此类.即可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受Redis的定时持久化,操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外,Redis还提供了下面一些操作:

      • 获取字符串长度
      • 往字符串append内容
      • 设置和获取字符串的某一段内容
      • 设置及获取字符串的某一位(bit)
      • 批量设置一系列字符串的内容

实现方式:String在redis内部存储默认就是一个字符串,被redisObject所引用,当遇到incr,decr等操作时会转成数值型进行计算,此时redisObject的encoding字段为int。

  • Hash

常用命令:hget,hset,hgetall 等。

应用场景:在Memcached中,我们经常将一些结构化的信息打包成HashMap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

我们简单举个实例来描述下Hash的应用场景,比如我们要存储一个用户信息对象数据,包含以下信息:

用户ID为查找的key,存储的value用户对象包含姓名,年龄,生日等信息,如果用普通的key/value结构来存储,主要有以下2种存储方式:

第一种方式将用户ID作为查找key,把其他信息封装成一个对象以序列化的方式存储,这种方式的缺点是,增加了序列化/反序列化的开销,并且在需要修改其中一项信息时,需要把整个对象取回,并且修改操作需要对并发进行保护,引入CAS等复杂问题。

第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿,用用户ID+对应属性的名称作为唯一标识来取得对应属性的值,虽然省去了序列化开销和并发问题,但是用户ID为重复存储,如果存在大量这样的数据,内存浪费还是非常可观的。

那么Redis提供的Hash很好的解决了这个问题,Redis的Hash实际是内部存储的Value为一个HashMap,并提供了直接存取这个Map成员的接口,如下图:

也就是说,Key仍然是用户ID, value是一个Map,这个Map的key是成员的属性名,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。

这里同时需要注意,Redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部Map的成员很多,那么涉及到遍历整个内部Map的操作,由于Redis单线程模型的缘故,这个遍历操作可能会比较耗时,而另其它客户端的请求完全不响应,这点需要格外注意。

实现方式:

上面已经说到Redis Hash对应Value内部实际就是一个HashMap,实际这里会有2种不同实现,这个Hash的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储,而不会采用真正的HashMap结构,对应的value redisObject的encoding为zipmap,当成员数量增大时会自动转成真正的HashMap,此时encoding为ht。

  • List

常用命令:lpush,rpush,lpop,rpop,lrange等。

应用场景:

Redis list的应用场景非常多,也是Redis最重要的数据结构之一,比如twitter的关注列表,粉丝列表等都可以用Redis的list结构来实现。

Lists 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用Lists结构,我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列,
可以利用Lists的PUSH操作,将任务存在Lists中,然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api,你可以直接查询,删除Lists中某一段的元素。

实现方式:

Redis list的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。

  • Set

常用命令:

sadd,spop,smembers,sunion 等。

应用场景:

Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。

Sets 集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

实现方式:

set 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。

  • Sorted Set

常用命令:

zadd,zrange,zrem,zcard等

使用场景:

Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。当你需要一个有序的并且不重复的集合列表,那么可以选择sorted set数据结构,比如twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。

另外还可以用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

实现方式:

Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。

  • Pub/Sub

Pub/Sub 从字面上理解就是发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

  • Transactions

谁说NoSQL都不支持事务,虽然Redis的Transactions提供的并不是严格的ACID的事务(比如一串用EXEC提交执行的命令,在执行中服务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个Transactions还是提供了基本的命令打包执行的功能(在服务器不出问题的情况下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。Redis还提供了一个Watch功能,你可以对一个key进行Watch,然后再执行Transactions,在这过程中,如果这个Watched的值进行了修改,那么这个Transactions会发现并拒绝执行。

4.  Redis实际应用场景

        Redis在很多方面与其他数据库解决方案不同:它使用内存提供主存储支持,而仅使用硬盘做持久性的存储;它的数据模型非常独特,用的是单线程。另一个大区别在于,你可以在开发环境中使用Redis的功能,但却不需要转到Redis。

转向Redis当然也是可取的,许多开发者从一开始就把Redis作为首选数据库;但设想如果你的开发环境已经搭建好,应用已经在上面运行了,那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用,Redis也并不适合,因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用,而且主要是读取访问模式,那么Redis并不是正确的选择。

        然而我喜欢Redis的一点就是你可以把它融入到你的系统中来,这就能够解决很多问题,比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化,或者为应用创建些新的功能。在本文中,我就想探讨一些怎样将Redis加入到现有的环境中,并利用它的原语命令等功能来解决 传统环境中碰到的一些常见问题。在这些例子中,Redis都不是作为首选数据库。

1、显示最新的项目列表

下面这个语句常用来显示最新项目,随着数据多了,查询毫无疑问会越来越慢。

[sql] view plain copy

  1. SELECT * FROM foo WHERE … ORDER BY time DESC LIMIT 10

        在Web应用中,“列出最新的回复”之类的查询非常普遍,这通常会带来可扩展性问题。这令人沮丧,因为项目本来就是按这个顺序被创建的,但要输出这个顺序却不得不进行排序操作。

        类似的问题就可以用Redis来解决。比如说,我们的一个Web应用想要列出用户贴出的最新20条评论。在最新的评论边上我们有一个“显示全部”的链接,点击后就可以获得更多的评论。

        我们假设数据库中的每条评论都有一个唯一的递增的ID字段。

        我们可以使用分页来制作主页和评论页,使用Redis的模板,每次新评论发表时,我们会将它的ID添加到一个Redis列表:

[plain] view plain copy

  1. LPUSH latest.comments <ID>

       我们将列表裁剪为指定长度,因此Redis只需要保存最新的5000条评论:

       LTRIM latest.comments 0 5000

      每次我们需要获取最新评论的项目范围时,我们调用一个函数来完成(使用伪代码):

[plain] view plain copy

  1. FUNCTION get_latest_comments(start, num_items):
  2.     id_list = redis.lrange(“latest.comments”,start,start+num_items – 1)
  3.     IF id_list.length < num_items
  4.         id_list = SQL_DB(“SELECT … ORDER BY time LIMIT …”)
  5.     END
  6.     RETURN id_list
  7. END

 

      这里我们做的很简单。在Redis中我们的最新ID使用了常驻缓存,这是一直更新的。但是我们做了限制不能超过5000个ID,因此我们的获取ID函数会一直询问Redis。只有在start/count参数超出了这个范围的时候,才需要去访问数据库。

        我们的系统不会像传统方式那样“刷新”缓存,Redis实例中的信息永远是一致的。SQL数据库(或是硬盘上的其他类型数据库)只是在用户需要获取“很远”的数据时才会被触发,而主页或第一个评论页是不会麻烦到硬盘上的数据库了。

2、删除与过滤

      我们可以使用LREM来删除评论。如果删除操作非常少,另一个选择是直接跳过评论条目的入口,报告说该评论已经不存在。

       有些时候你想要给不同的列表附加上不同的过滤器。如果过滤器的数量受到限制,你可以简单的为每个不同的过滤器使用不同的Redis列表。毕竟每个列表只有5000条项目,但Redis却能够使用非常少的内存来处理几百万条项目。

3、排行榜相关

      另一个很普遍的需求是各种数据库的数据并非存储在内存中,因此在按得分排序以及实时更新这些几乎每秒钟都需要更新的功能上数据库的性能不够理想。

      典型的比如那些在线游戏的排行榜,比如一个Facebook的游戏,根据得分你通常想要:

         – 列出前100名高分选手

         – 列出某用户当前的全球排名

      这些操作对于Redis来说小菜一碟,即使你有几百万个用户,每分钟都会有几百万个新的得分。

      模式是这样的,每次获得新得分时,我们用这样的代码:

      ZADD leaderboard  <score>  <username>

     你可能用userID来取代username,这取决于你是怎么设计的。

      得到前100名高分用户很简单:ZREVRANGE leaderboard 0 99。

      用户的全球排名也相似,只需要:ZRANK leaderboard <username>。

4、按照用户投票和时间排序

      排行榜的一种常见变体模式就像Reddit或Hacker News用的那样,新闻按照类似下面的公式根据得分来排序:

       score = points / time^alpha

      因此用户的投票会相应的把新闻挖出来,但时间会按照一定的指数将新闻埋下去。下面是我们的模式,当然算法由你决定。

      模式是这样的,开始时先观察那些可能是最新的项目,例如首页上的1000条新闻都是候选者,因此我们先忽视掉其他的,这实现起来很简单。

      每次新的新闻贴上来后,我们将ID添加到列表中,使用LPUSH + LTRIM,确保只取出最新的1000条项目。

      有一项后台任务获取这个列表,并且持续的计算这1000条新闻中每条新闻的最终得分。计算结果由ZADD命令按照新的顺序填充生成列表,老新闻则被清除。这里的关键思路是排序工作是由后台任务来完成的。

5、处理过期项目

      另一种常用的项目排序是按照时间排序。我们使用unix时间作为得分即可。

      模式如下:

       – 每次有新项目添加到我们的非Redis数据库时,我们把它加入到排序集合中。这时我们用的是时间属性,current_time和time_to_live。

       – 另一项后台任务使用ZRANGE…SCORES查询排序集合,取出最新的10个项目。如果发现unix时间已经过期,则在数据库中删除条目。

6、计数

       Redis是一个很好的计数器,这要感谢INCRBY和其他相似命令。

       我相信你曾许多次想要给数据库加上新的计数器,用来获取统计或显示新信息,但是最后却由于写入敏感而不得不放弃它们。

       好了,现在使用Redis就不需要再担心了。有了原子递增(atomic increment),你可以放心的加上各种计数,用GETSET重置,或者是让它们过期。

       例如这样操作:

         INCR user:<id> EXPIRE

         user:<id> 60

       你可以计算出最近用户在页面间停顿不超过60秒的页面浏览量,当计数达到比如20时,就可以显示出某些条幅提示,或是其它你想显示的东西。

7、特定时间内的特定项目

        另一项对于其他数据库很难,但Redis做起来却轻而易举的事就是统计在某段特点时间里有多少特定用户访问了某个特定资源。比如我想要知道某些特定的注册用户或IP地址,他们到底有多少访问了某篇文章。

      每次我获得一次新的页面浏览时我只需要这样做:

       SADD page:day1:<page_id> <user_id>

      当然你可能想用unix时间替换day1,比如time()-(time()%3600*24)等等。

      想知道特定用户的数量吗?只需要使用SCARD page:day1:<page_id>。

       需要测试某个特定用户是否访问了这个页面?SISMEMBER page:day1:<page_id>。

8、实时分析正在发生的情况,用于数据统计与防止垃圾邮件等

        我们只做了几个例子,但如果你研究Redis的命令集,并且组合一下,就能获得大量的实时分析方法,有效而且非常省力。使用Redis原语命令,更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

9、Pub/Sub

       Redis的Pub/Sub非常非常简单,运行稳定并且快速。支持模式匹配,能够实时订阅与取消频道。

10、队列

        你应该已经注意到像list push和list pop这样的Redis命令能够很方便的执行队列操作了,但能做的可不止这些:比如Redis还有list pop的变体命令,能够在列表为空时阻塞队列。

       现代的互联网应用大量地使用了消息队列(Messaging)。消息队列不仅被用于系统内部组件之间的通信,同时也被用于系统跟其它服务之间的交互。消息队列的使用可以增加系统的可扩展性、灵活性和用户体验。非基于消息队列的系统,其运行速度取决于系统中最慢的组件的速度(注:短板效应)。而基于消息队列可以将系统中各组件解除耦合,这样系统就不再受最慢组件的束缚,各组件可以异步运行从而得以更快的速度完成各自的工作。

    此外,当服务器处在高并发操作的时候,比如频繁地写入日志文件。可以利用消息队列实现异步处理。从而实现高性能的并发操作。

11、缓存

        Redis的缓存部分值得写一篇新文章,我这里只是简单的说一下。Redis能够替代memcached,让你的缓存从只能存储数据变得能够更新数据,因此你不再需要每次都重新生成数据了。

此部分内容的原文地址:http://antirez.com/post/take-advantage-of-redis-adding-it-to-your-stack.html

 

5.  国内外三个不同领域巨头分享的Redis实战经验及使用场景

     随着应用对高性能需求的增加,NoSQL逐渐在各大名企的系统架构中生根发芽。这里我们将为大家分享社交巨头新浪微博、传媒巨头Viacom及图片分享领域佼佼者Pinterest带来的Redis实践,首先我们看新浪微博 @启盼cobain的Redis实战经验分享:

一、新浪微博:史上最大的Redis集群

Tape is Dead,Disk is Tape,Flash is Disk,RAM Locality is King. — Jim Gray

Redis不是比较成熟的memcache或者Mysql的替代品,是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况:

  • 2200+亿 commands/day 5000亿Read/day 500亿Write/day
  • 18TB+ Memory
  • 500+ Servers in 6 IDC 2000+instances

应该是国内外比较大的Redis使用平台,今天主要从应用角度谈谈Redis服务平台。

Redis使用场景

1.Counting(计数)

计数的应用在另外一篇文章里较详细的描述,计数场景的优化 http://www.xdata.me/?p=262这里就不多加描述了。

可以预见的是,有很多同学认为把计数全部存在内存中成本非常高,我在这里用个图表来表达下我的观点:

很多情况大家都会设想纯使用内存的方案会很有很高成本,但实际情况往往会有一些不一样:

  • COST,对于有一定吞吐需求的应用来说,肯定会单独申请DB、Cache资源,很多担心DB写入性能的同学还会主动将DB更新记入异步队列,而这三块的资源的利用率一般都不会太高。资源算下来,你惊异的发现:反而纯内存的方案会更精简!
  • KISS原则,这对于开发是非常友好的,我只需要建立一套连接池,不用担心数据一致性的维护,不用维护异步队列。
  • Cache穿透风险,如果后端使用DB,肯定不会提供很高的吞吐能力,cache宕机如果没有妥善处理,那就悲剧了。
  • 大多数的起始存储需求,容量较小。

2.Reverse cache(反向cache)

面对微博常常出现的热点,如最近出现了较为火爆的短链,短时间有数以万计的人点击、跳转,而这里会常常涌现一些需求,比如我们向快速在跳转时判定用户等级,是否有一些账号绑定,性别爱好什么的,已给其展示不同的内容或者信息。

普通采用memcache+Mysql的解决方案,当调用id合法的情况下,可支撑较大的吞吐。但当调用id不可控,有较多垃圾用户调用时,由于memcache未有命中,会大量的穿透至Mysql服务器,瞬间造成连接数疯长,整体吞吐量降低,响应时间变慢。

这里我们可以用redis记录全量的用户判定信息,如string key:uid int:type,做一次反向的cache,当用户在redis快速获取自己等级等信息后,再去Mc+Mysql层去获取全量信息。如图:

当然这也不是最优化的场景,如用Redis做bloomfilter,可能更加省用内存。

3.Top 10 list

产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的top list。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大,鉴于占用内存较小的情况,使用Redis做存储也是相当不错的。

4.Last Index

用户最近访问记录也是redis list的很好应用场景,lpush lpop自动过期老的登陆记录,对于开发来说还是非常友好的。

5.Relation List/Message Queue

这里把两个功能放在最后,因为这两个功能在现实问题当中遇到了一些困难,但在一定阶段也确实解决了我们很多的问题,故在这里只做说明。

Message Queue就是通过list的lpop及lpush接口进行队列的写入和消费,由于本身性能较好也能解决大部分问题。

6.Fast transaction with Lua

Redis 的Lua的功能扩展实际给Redis带来了更多的应用场景,你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑,如:在收到message推送时,同时1.给自己的增加一个未读的对话 2.给自己的私信增加一个未读消息 3.最后给发送人回执一个完成推送消息,这一层逻辑完全可以在Redis Server端实现。

但是,需要注意的是Redis会将lua script的全部内容记录在aof和传送给slave,这也将是对磁盘,网卡一个不小的开销。

7.Instead of Memcache

  1. 很多测试和应用均已证明,
  2. 在性能方面Redis并没有落后memcache多少,而单线程的模型给Redis反而带来了很强的扩展性。
  3. 在很多场景下,Redis对同一份数据的内存开销是小于memcache的slab分配的。
  4. Redis提供的数据同步功能,其实是对cache的一个强有力功能扩展。

Redis使用的重要点

1.rdb/aof Backup!

我们线上的Redis 95%以上是承担后端存储功能的,我们不仅用作cache,而更为一种k-v存储,他完全替代了后端的存储服务(MySQL),故其数据是非常重要的,如果出现数据污染和丢失,误操作等情况,将是难以恢复的。所以备份是非常必要的!为此,我们有共享的hdfs资源作为我们的备份池,希望能随时可以还原业务所需数据。

2.Small item & Small instance!

由于Redis单线程(严格意义上不是单线程,但认为对request的处理是单线程的)的模型,大的数据结构list,sorted set,hash set的批量处理就意味着其他请求的等待,故使用Redis的复杂数据结构一定要控制其单key-struct的大小。

另外,Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后,直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长,而更糟糕的是,Redis rewrite aof和save rdb时,将会带来非常大且长的系统压力,并占用额外内存,很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。

3.Been Available!

业界资料和使用比较多的是Redis sentinel(哨兵)

http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.html

http://qiita.com/wellflat/items/8935016fdee25d4866d9

2000行C实现了服务器状态检测,自动故障转移等功能。

但由于自身实际架构往往会复杂,或者考虑的角度比较多,为此 @许琦eryk和我一同做了hypnos项目。

hypnos是神话中的睡神,字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)

其工作原理示意如下:

Talk is cheap, show me your code! 稍后将单独写篇博客细致讲下Hypnos的实现。

4.In Memory or not?

发现一种情况,开发在沟通后端资源设计的时候,常常因为习惯使用和错误了解产品定位等原因,而忽视了对真实使用用户的评估。也许这是一份历史数据,只有最近一天的数据才有人进行访问,而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。

所以当你在究竟使用什么样的数据结构存储的时候,请务必先进行成本衡量,有多少数据是需要存储在内存中的?有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的,1G的数据容量和1T的数据容量对于设计思路是完全不一样的

Plans in future?

1.slave sync改造

全部改造线上master-slave数据同步机制,这一点我们借鉴了MySQL Replication的思路,使用rdb+aof+pos作为数据同步的依据,这里简要说明为什么官方提供的psync没有很好的满足我们的需求:

假设A有两个从库B及C,及 A `— B&C,这时我们发现master A服务器有宕机隐患需要重启或者A节点直接宕机,需要切换B为新的主库,如果A、B、C不共享rdb及aof信息,C在作为B的从库时,仍会清除自身数据,因为C节点只记录了和A节点的同步状况。

故我们需要有一种将A`–B&C 结构切换切换为A`–B`–C结构的同步机制,psync虽然支持断点续传,但仍无法支持master故障的平滑切换。

实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步,效果非常好,解决了运维负担,但仍需向所有Redis服务推广,如果可能我们也会向官方Redis提出相关sync slave的改进。

2.更适合redis的name-system Or proxy

细心的同学发现我们除了使用DNS作为命名系统,也在zookeeper中有一份记录,为什么不让用户直接访问一个系统,zk或者DNS选择其一呢?

其实还是很简单,命名系统是个非常重要的组件,而dns是一套比较完善的命名系统,我们为此做了很多改进和试错,zk的实现还是相对复杂,我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。

3.后端数据存储

大内存的使用肯定是一个重要的成本优化方向,flash盘及分布式的存储也在我们未来计划之中。(原文链接: Largest Redis Clusters Ever

二、Pinterest:Reids维护上百亿的相关性

Pinterest已经成为硅谷最疯故事之一,在2012年,他们基于PC的业务增加1047%,移动端采用增加1698%, 该年3月其独立访问数量更飙升至533亿。在Pinterest,人们关注的事物以百亿记——每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展,Pinterest已经成为媒体、社交等多个领域的佼佼者,其辉煌战绩如下:

  • 获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和
  • 与Facebook及Twitter一起成为最流行的三大社交网络
  • 参考Pinterest进行购买的用户比其它网站更高( 更多详情

如您所想,基于其独立访问数,Pinterest的高规模促成了一个非常高的IT基础设施需求。

 

通过缓存来优化用户体验

近日,Pinterest工程经理Abhi Khune对其公司的用户体验需求及Redis的使用经验 进行了分享。即使是滋生的应用程序打造者,在分析网站的细节之前也不会理解这些特性,因此先大致的理解一下使用场景:首先,为每个粉丝进行提及到的预检查;其次,UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作,每次点击都需要非常高的性能架构。

不能免俗,Pinterest的软件工程师及架构师已经使用了MySQL及memcache,但是缓存解决方案仍然达到了他们的瓶颈;因此为了拥有更好的用户体验,缓存必须被扩充。而在实际操作过程中,工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任何使用这个系统的人都需要被缓存,这就导致了整个图的缓存。同时,最常见的查询“用户A是否关注了用户B”的答案经常是否定的,然而这却被作为了缓存丢失,从而促成一个数据库查询,因此他们需要一个新的方法来扩展缓存。最终,他们团队决定使用Redis来存储整个图,用以服务众多的列表。

使用Redis存储大量的Pinterest列表

Pinterest使用了Redis作为解决方案,并将性能推至了内存数据库等级,为用户保存多种类型列表:

  • 关注者列表
  • 你所关注的board列表
  • 粉丝列表
  • 关注你board的用户列表
  • 某个用户中board中你没有关注的列表
  • 每个board的关注者及非关注者

Redis为其7000万用户存储了以上的所有列表,本质上讲可以说是储存了所有粉丝图,通过用户ID分片。鉴于你可以通过类型来查看以上列表的数据,分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万,初略进行统计:如果每个用户关注25个board,将会在用户及board间产生17.5亿的关系。同时更加重要的是,这些关系随着系统的使用每天都会增加。

Pinterest的Reids架构及运营

通过Pinterest的一个创始人了解到,Pinterest开始使用Python及订制的Django编写应用程序,并一直持续到其拥有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存,工程师根据用户id使用了8192个虚拟分片,每个分片都运行在一个Redis DB之上,同时1个Redis实例将运行多个Redis DB。为了对CPU核心的充分使用,同一台主机上同时使用多线程和单线程Redis实例。

鉴于整个数据集运行在内存当中,Redis在Amazon EBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行:第一,保持50%的利用率,通过主从转换,机器上运行的Redis实例一半会转译到一个新机器上;第二,扩展节点和分片。整个Redis集群都会使用一个主从配置,从部分将被当做一个热备份。一旦主节点失败,从部分会立刻完成主的转换,同时一个新的从部分将会被添加,ZooKeeper将完成整个过程。同时他们每个小时都会在Amazon S3上运行BGsave做更持久的储存——这项Reids操作会在后端进行,之后Pinterest会使用这些数据做MapReduce和分析作业。(更多内容见原文)

三、Viacom:Redis在系统中的用例盘点

Viacom是全球最大的传媒集体之一,同时也遭遇了当下最大的数据难题之一:如何处理日益剧增的动态视频内容。

着眼这一挑战的上升趋势,我们会发现:2010年世界上所有数据体积达到ZB级,而单单2012这一年,互联网产生的数据就增加了2.8个ZB,其中大部分的数据都是非结构化的,包括了视频和图片。

覆盖MVN(以前称为MTV Networks、Paramount及BET),Viacom是个名副其实的传媒巨头,支持众多人气站点,其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。作为媒体公司,这些网站上的文档、图片、视频短片都在无时无刻的更新。长话短说,下面就进入Viacom高级架构师Michael Venezia 分享的Redis实践:

Viacom的网站架构背景

对于Viacom,横跨多个站点传播内容让必须专注于规模的需求,同时为了将内容竟可能快的传播到相应用户,他们还必须聚焦内容之间的关系。然而即使The Daily Show、Nickelodeon、Spike或者是VH1 这些单独的网站上,日平均PV都可以达到千万,峰值时流量更会达到平均值的20-30倍。同时基于对实时的需求,动态的规模及速度已成为架构的基础之一。

除去动态规模之外,服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说,某个页面可能会将一个独立的视频片段与本地的促销,视频系列的额外部分,甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间,他们建立了一个能基于详细元数据自动建立页面的软件引擎,这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变,数据的类型非常广泛——类似graph-like,实际上做的是大量的join。

这样做有利于减少类似视频的大体积文件副本数,比如数据存储中一个独立的记录是Southpark片段“Cartman gets an Anal Probe”,这个片段可能也会出现在德语的网站上。虽然视频是一样的,但是英语用户搜索的可能就是另一个不同的词语。元数据的副本转换成搜索结果,并指向相同的视频。因此在美国用户搜索真实标题的情况下,德国浏览者可能会使用转译的标题——德国网站上的“Cartman und die Analsonde”。

这些元数据覆盖了其它记录或者是对象,同时还可以根据使用环境来改变内容,通过不同的规则集来限制不同地理位置或者是设备请求的内容。

Viacom的实现方法

尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题,Viacom却使用了一个迥然不同的方法。

本质上,他们完全承担不了对数据库的直接访问。首先,他们处理的大部分都是流数据,他们偏向于使用Akamai从地理上来分配内容。其次,基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能,因此JSON在1个数据服务中投入了使用。当然,这些JSON对象的缓存将直接影响到网站性能。同时,当内容或者是内容之间的关系发生改变时,缓存还需要动态的进行更新。

Viacom依靠对象基元和超类解决这个问题,继续以South Park为例:一个私有的“episode”类包含了所有该片段相关信息,一个“super object”将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设,这些超类可以帮助到基元对象到缓存的映射及保存。

Viacom为什么要使用Redis

每当Viacom上传一个视频片段,系统将建立一个私有的对象,并于1个超类关联。每一次修改,他们都需要重估私有对象的每个改变,并更新所有复合对象。同时,系统还需要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。

基于Viacom主要基于PHP,所以这个解决方案必须支持PHP。他们首先选择了memcached做对象存储,但是它并不能很好的支持hashmap;同时他们还需要一个更有效的进行无效步骤的重估,即更好的理解内容的依赖性。本质上说,他们需要时刻跟进无效步骤中的依赖性改变。因此他们选择了Redis及Predis的组合来解决这个问题。

他们团队使用Redis给southparkstudios.com和thedailyshow.com两个网站建设依赖性图,在取得了很大的成功后他们开始着眼Redis其它适合场景。

Redis的其它使用场景

显而易见,如果有人使用Redis来建设依赖性图,那么使用它来做对象处理也是说得通的。同样,这也成了架构团队为Redis选择的第二使用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队,因此在几个开发周期后,Redis成为他们网站的主要数据及依赖性储存。

后两个用例则是行为追踪及浏览计数的缓冲,改变后的架构是Redis每几分钟向MySQL中储存一次,而浏览计数则通过Redis进行存储及计数。同时Redis还被用来做人气的计算,一个基于访问数及访问时间的得分系统——如果某个视频最近被访问的次数越多,它的人气就越高。在如此多内容上每隔10-15分钟做一次计算绝对不是类似MySQL这样传统关系型数据库的强项,Viacom使用Redis的理由也非常简单——在1个存储浏览信息的Redis实例上运行Lua批处理作业,计算出所有的得分表。信息被拷贝到另一个Redis实例上,用以支持相关的产品查询。同时还在MySQL上做了另一个备份,用以以后的分析,这种组合会将这个过程耗费的时间降低60倍。

Viacom还使用Redis存储一步作业信息,这些信息被插入一个列表中,工作人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络(比如Twitter及Tumblr)上综合内容,Viacom通过Brightcove视频播放器来同步多个内容管理系统。

横跨这些用例,几乎所有的Redis命令都被使用——sets、lists、zlists、hashmaps、scripts、counters等。同时,Redis也成为Viacom可扩展架构中不可或缺的一环。

系统吞吐量、TPS(QPS)、用户并发量、性能测试概念和公式

一.系统吞度量要素:

一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高,外部系统接口、IO影响速度越慢,系统吞吐能力越低,反之越高。

系统吞吐量几个重要参数:QPS(TPS)、并发数、响应时间

QPS(TPS):每秒钟request/事务 数量

并发数: 系统同时处理的request/事务数

响应时间:  一般取平均响应时间

(很多人经常会把并发数和TPS理解混淆)

理解了上面三个要素的意义之后,就能推算出它们之间的关系:
QPS(TPS)= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间
一个典型的上班签到系统,早上8点上班,7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人,平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。
QPS = 1000/(30*60) 事务/秒
平均响应时间为 = 5*60  秒
并发数= QPS*平均响应时间 = 1000/(30*60) *(5*60)=166.7

一个系统吞吐量通常由QPS(TPS)、并发数两个因素决定,每套系统这两个值都有一个相对极限值,在应用场景访问压力下,只要某一项达到系统最高值,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等等其它消耗导致系统性能下降。

决定系统响应时间要素

我们做项目要排计划,可以多人同时并发做多项任务,也可以一个人或者多个人串行工作,始终会有一条关键路径,这条路径就是项目的工期。

系统一次调用的响应时间跟项目计划一样,也有一条关键路径,这个关键路径是就是系统影响时间;

关键路径是有CPU运算、IO、外部系统响应等等组成。

二.系统吞吐量评估:

我们在做系统设计的时候就需要考虑CPU运算、IO、外部系统响应因素造成的影响以及对系统性能的初步预估。

而通常境况下,我们面对需求,我们评估出来的出来QPS、并发数之外,还有另外一个维度:日PV。

通过观察系统的访问日志发现,在用户量很大的情况下,各个时间周期内的同一时间段的访问流量几乎一样。比如工作日的每天早上。只要能拿到日流量图和QPS我们就可以推算日流量。

通常的技术方法:

1. 找出系统的最高TPS和日PV,这两个要素有相对比较稳定的关系(除了放假、季节性因素影响之外)

2. 通过压力测试或者经验预估,得出最高TPS,然后跟进1的关系,计算出系统最高的日吞吐量。B2B中文和淘宝面对的客户群不一样,这两个客户群的网络行为不应用,他们之间的TPS和PV关系比例也不一样。

A)淘宝

淘宝流量图:

系统吞吐量评估方法

淘宝的TPS和PV之间的关系通常为  最高TPS:PV大约为 1 : 11*3600 (相当于按最高TPS访问11个小时,这个是商品详情的场景,不同的应用场景会有一些不同)

B) B2B中文站

B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大,粗略估计在1 : 8个小时左右的关系(09年对offerdetail的流量分析数据)。旺铺和offerdetail这两个比例相差很大,可能是因为爬虫暂的比例较高的原因导致。

在淘宝环境下,假设我们压力测试出的TPS为100,那么这个系统的日吞吐量=100*11*3600=396万

这个是在简单(单一url)的情况下,有些页面,一个页面有多个request,系统的实际吞吐量还要小。

无论有无思考时间(T_think),测试所得的TPS值和并发虚拟用户数(U_concurrent)、Loadrunner读取的交易响应时间(T_response)之间有以下关系(稳定运行情况下):
TPS=U_concurrent / (T_response+T_think)。

并发数、QPS、平均响应时间三者之间关系

系统吞吐量评估方法

上图横坐标是并发用户数。绿线是CPU使用率;紫线是吞吐量,即QPS;蓝线是时延。
开始,系统只有一个用户,CPU工作肯定是不饱合的。一方面该服务器可能有多个cpu,但是只处理单个进程,另一方面,在处理一个进程中,有些阶段可能是IO阶段,这个时候会造成CPU等待,但是有没有其他请 求进程可以被处理)。随着并发用户数的增加,CPU利用率上升,QPS相应也增加(公式为QPS=并发用户数/平均响应时间。)随着并发用户数的增加,平均响应时间也在增加,而且平均响应时间的增加是一个指数增加曲线。而当并发数增加到很大时,每秒钟都会有很多请求需要处理,会造成进程(线程)频繁切换,反正真正用于处理请求的时间变少,每秒能够处 理的请求数反而变少,同时用户的请求等待时间也会变大,甚至超过用户的心理底线。

来源:http://www.cnblogs.com/jackei/

软件性能测试的基本概念和计算公式

一、软件性能的关注点

对一个软件做性能测试时需要关注那些性能呢?

我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与,然后再考虑这些角色各自关注的性能点是什么,作为一个软件性能测试工程师,我们又该关注什么?

首先,开发软件的目的是为了让用户使用,我们先站在用户的角度分析一下,用户需要关注哪些性能。

对于用户来说,当点击一个按钮、链接或发出一条指令开始,到系统把结果已用户感知的形式展现出来为止,这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间,当相应时间较小时,用户体验是很好的,当然用户体验的响应时间包括个人主观因素和客观响应时间,在设计软件时,我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如:用户在大数据量查询时,我们可以将先提取出来的数据展示给用户,在用户看的过程中继续进行数据检索,这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次,我们站在管理员的角度考虑需要关注的性能点。

1、 相应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问

再次,站在开发(设计)人员角度去考虑。

1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争

那么站在性能测试工程师的角度,我们要关注什么呢?

一句话,我们要关注以上所有的性能点。

二、软件性能的几个主要术语

1、响应时间:对请求作出响应所需要的时间

网络传输时间:N1+N2+N3+N4

应用服务器处理时间:A1+A3

数据库服务器处理时间:A2

响应时间=N1+N2+N3+N4+A1+A3+A2

2、并发用户数的计算公式

系统用户数:系统额定的用户数量,如一个OA系统,可能使用该系统的用户总数是5000个,那么这个数量,就是系统用户数。

同时在线用户数:在一定的时间范围内,最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS(吞吐量)+并发连接数+平均用户思考时间

平均并发用户数的计算:C=nL / T

其中C是平均的并发用户数,n是平均每天访问用户数(login session),L是一天内用户从登录到退出的平均时间(login session的平均时间),T是考察时间长度(一天内多长时间有用户使用系统)

并发用户数峰值计算:C^约等于C + 3*根号C

其中C^是并发用户峰值,C是平均并发用户数,该公式遵循泊松分布理论。

3、吞吐量的计算公式

指单位时间内系统处理用户的请求数

从业务角度看,吞吐量可以用:请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

从网络角度看,吞吐量可以用:字节/秒来衡量

对于交互式应用来说,吞吐量指标反映的是服务器承受的压力,他能够说明系统的负载能力

以不同方式表达的吞吐量可以说明不同层次的问题,例如,以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈;已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

当没有遇到性能瓶颈的时候,吞吐量与虚拟用户数之间存在一定的联系,可以采用以下公式计算:F=VU * R /

其中F为吞吐量,VU表示虚拟用户个数,R表示每个虚拟用户发出的请求数,T表示性能测试所用的时间

4、性能计数器

是描述服务器或操作系统性能的一些数据指标,如使用内存数、进程时间,在性能测试中发挥着“监控和分析”的作用,尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

资源利用率:指系统各种资源的使用情况,如cpu占用率为68%,内存占用率为55%,一般使用“资源实际使用/总的资源可用量”形成资源利用率。

5、思考时间的计算公式

Think Time,从业务角度来看,这个时间指用户进行操作时每个请求之间的时间间隔,而在做新能测试时,为了模拟这样的时间间隔,引入了思考时间这个概念,来更加真实的模拟用户的操作。

在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数,而其中的R又可以用时间T和用户思考时间TS来计算:R = T / TS

下面给出一个计算思考时间的一般步骤:

A、首先计算出系统的并发用户数

C=nL / T F=R×C

B、统计出系统平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、统计出平均每个用户发出的请求数量

R=u*C*T/VU

D、根据公式计算出思考时间

TS=T/R

LINUX常用操作命令

  • 常用指令
    ls 显示文件或目录
    -l 列出文件详细信息l(list)
    -a 列出当前目录下所有文件及目录,包括隐藏的a(all)
    mkdir 创建目录
    -p 创建目录,若无父目录,则创建p(parent)
    cd 切换目录
    touch 创建空文件
    echo 创建带有内容的文件。
    cat 查看文件内容
    cp 拷贝
    mv 移动或重命名
    rm 删除文件
    -r 递归删除,可删除子目录及文件
    -f 强制删除
    find 在文件系统中搜索某文件
    wc 统计文本中行数、字数、字符数
    grep 在文本文件中查找某个字符串
    rmdir 删除空目录
    tree 树形结构显示目录,需要安装tree包
    pwd 显示当前目录
    ln 创建链接文件
    more、less 分页显示文本文件内容
    head、tail 显示文件头、尾内容
    ctrl+alt+F1 命令行全屏模式
  • 系统管理命令
    stat 显示指定文件的详细信息,比ls更详细
    who 显示在线登陆用户
    whoami 显示当前操作用户
    hostname 显示主机名
    uname 显示系统信息
    top 动态显示当前耗费资源最多进程信息
    ps 显示瞬间进程状态 ps -aux
    du 查看目录大小 du -h /home带有单位显示目录信息
    df 查看磁盘大小 df -h 带有单位显示磁盘信息
    ifconfig 查看网络情况
    ping 测试网络连通
    netstat 显示网络状态信息
    man 命令不会用了,找男人? 如:man ls
    clear 清屏
    alias 对命令重命名 如:alias showmeit=”ps -aux” ,另外解除使用unaliax showmeit
    kill 杀死进程,可以先用ps 或 top命令查看进程的id,然后再用kill命令杀死进程。
  • 打包压缩相关命令
    gzip:
    bzip2:
    tar: 打包压缩
    -c 归档文件
    -x 压缩文件
    -z gzip压缩文件
    -j bzip2压缩文件
    -v 显示压缩或解压缩过程 v(view)
    -f 使用档名
    例:
    tar -cvf /home/abc.tar /home/abc 只打包,不压缩
    tar -zcvf /home/abc.tar.gz /home/abc 打包,并用gzip压缩
    tar -jcvf /home/abc.tar.bz2 /home/abc 打包,并用bzip2压缩
    当然,如果想解压缩,就直接替换上面的命令tar -cvf / tar -zcvf / tar -jcvf 中的“c” 换成“x” 就可以了。
  • 关机/重启机器
    shutdown
    -r 关机重启
    -h 关机不重启
    now 立刻关机
    halt 关机
    reboot 重启
  • Linux管道
    将一个命令的标准输出作为另一个命令的标准输入。也就是把几个命令组合起来使用,后一个命令除以前一个命令的结果。
    例:grep -r “close” /home/* | more 在home目录下所有文件中查找,包括close的文件,并分页输出。
  • Linux软件包管理
    dpkg (Debian Package)管理工具,软件包名以.deb后缀。这种方法适合系统不能联网的情况下。
    比如安装tree命令的安装包,先将tree.deb传到Linux系统中。再使用如下命令安装。
    sudo dpkg -i tree_1.5.3-1_i386.deb 安装软件
    sudo dpkg -r tree 卸载软件
    注:将tree.deb传到Linux系统中,有多种方式。VMwareTool,使用挂载方式;使用winSCP工具等;
    APT(Advanced Packaging Tool)高级软件工具。这种方法适合系统能够连接互联网的情况。
    依然以tree为例
    sudo apt-get install tree 安装tree
    sudo apt-get remove tree 卸载tree
    sudo apt-get update 更新软件
    sudo apt-get upgrade

将.rpm文件转为.deb文件
.rpm为RedHat使用的软件格式。在Ubuntu下不能直接使用,所以需要转换一下。
sudo alien abc.rpm

  • vim使用
    vim三种模式:命令模式、插入模式、编辑模式。使用ESC或i或:来切换模式。
    命令模式下:
    :q 退出
    :q! 强制退出
    :wq 保存并退出
    :set number 显示行号
    :set nonumber 隐藏行号
    /apache 在文档中查找apache 按n跳到下一个,shift+n上一个
    yyp 复制光标所在行,并粘贴
    h(左移一个字符←)、j(下一行↓)、k(上一行↑)、l(右移一个字符→)
  • 用户及用户组管理
    /etc/passwd 存储用户账号
    /etc/group 存储组账号
    /etc/shadow 存储用户账号的密码
    /etc/gshadow 存储用户组账号的密码
    useradd 添加用户名
    userdel 删除用户名
    adduser 添加用户名
    groupadd 添加组名
    groupdel 删除组名
    passwd root 给root设置密码
    su root
    su – root
    /etc/profile 系统环境变量
    bash_profile 用户环境变量
    .bashrc 用户环境变量
    su user 切换用户,加载配置文件.bashrc
    su – user 切换用户,加载配置文件/etc/profile ,加载bash_profile
  • 更改文件的用户及用户组
    sudo chown [-R] owner[:group] {File|Directory}
    例如:还以jdk-7u21-linux-i586.tar.gz为例。属于用户hadoop,组hadoop
    要想切换此文件所属的用户及组。可以使用命令。
    sudo chown root:root jdk-7u21-linux-i586.tar.gz
  • 文件权限管理
    三种基本权限
    R 读 数值表示为4
    W 写 数值表示为2
    X 可执行 数值表示为1

如jdk-7u21-linux-i586.tar.gz文件的权限为-rw-rw-r–
-rw-rw-r–一共十个字符,分成四段。
第一个字符“-”表示普通文件;这个位置还可能会出现“l”链接;“d”表示目录
第二三四个字符“rw-”表示当前所属用户的权限。 所以用数值表示为4+2=6
第五六七个字符“rw-”表示当前所属组的权限。 所以用数值表示为4+2=6
第八九十个字符“r–”表示其他用户权限。 所以用数值表示4为
所以操作此文件的权限用数值表示为664?

更改权限
sudo chmod [u所属用户 g所属组 o其他用户 a所有用户] [+增加权限 -减少权限] [r w x] 目录名
例如:有一个文件filename,权限为“-rw-r—-x” ,将权限值改为”-rwxrw-r-x”,用数值表示为765
sudo chmod u+x g+w o+r filename
上面的例子可以用数值表示
sudo chmod 765 filename

Redis的11种Web应用场景

“怎样让Redis在你的系统中发挥作用”一文中,Salvatore ‘antirez’ Sanfilippo告诉我们如何利用Redis独有的数据结构处理能力来解决一些常见问题。一些Redis原语命令比如LPUSH、LTRIM和LREM等等能够用来帮助开发者完成需要的任务——这些任务在传统的数据库存储中非常困难或缓慢。这是一篇非常有用并且实际的文章。那么要如何在你的框架中完成这些任务呢?

下面列出11种Web应用场景,在这些场景下可以充分的利用Redis的特性,大大提高效率。

1.在主页中显示最新的项目列表。

Redis使用的是常驻内存的缓存,速度非常快。LPUSH用来插入一个内容ID,作为关键字存储在列表头部。LTRIM用来限制列表中的项目数最多为5000。如果用户需要的检索的数据量超越这个缓存容量,这时才需要把请求发送到数据库。

2.删除和过滤。

如果一篇文章被删除,可以使用LREM从缓存中彻底清除掉。

3.排行榜及相关问题。

排行榜(leader board)按照得分进行排序。ZADD命令可以直接实现这个功能,而ZREVRANGE命令可以用来按照得分来获取前100名的用户,ZRANK可以用来获取用户排名,非常直接而且操作容易。

4.按照用户投票和时间排序。

这就像Reddit的排行榜,得分会随着时间变化。LPUSH和LTRIM命令结合运用,把文章添加到一个列表中。一项后台任务用来获取列表,并重新计算列表的排序,ZADD命令用来按照新的顺序填充生成列表。列表可以实现非常快速的检索,即使是负载很重的站点。

5.过期项目处理。

使用unix时间作为关键字,用来保持列表能够按时间排序。对current_time和time_to_live进行检索,完成查找过期项目的艰巨任务。另一项后台任务使用ZRANGE…WITHSCORES进行查询,删除过期的条目。

6.计数。

进行各种数据统计的用途是非常广泛的,比如想知道什么时候封锁一个IP地址。INCRBY命令让这些变得很容易,通过原子递增保持计数;GETSET用来重置计数器;过期属性用来确认一个关键字什么时候应该删除。

7.特定时间内的特定项目。

这是特定访问者的问题,可以通过给每次页面浏览使用SADD命令来解决。SADD不会将已经存在的成员添加到一个集合。

8.实时分析正在发生的情况,用于数据统计与防止垃圾邮件等。

使用Redis原语命令,更容易实施垃圾邮件过滤系统或其他实时跟踪系统。

9.Pub/Sub。

在更新中保持用户对数据的映射是系统中的一个普遍任务。Redis的pub/sub功能使用了SUBSCRIBE、UNSUBSCRIBE和PUBLISH命令,让这个变得更加容易。

10.队列。

在当前的编程中队列随处可见。除了push和pop类型的命令之外,Redis还有阻塞队列的命令,能够让一个程序在执行时被另一个程序添加到队列。你也可以做些更有趣的事情,比如一个旋转更新的RSS feed队列。

11.缓存。

Redis缓存使用的方式与memcache相同。

网络应用不能无休止地进行模型的战争,看看这些Redis的原语命令,尽管简单但功能强大,把它们加以组合,所能完成的就更无法想象。当然,你可以专门编写代码来完成所有这些操作,但Redis实现起来显然更为轻松。

MongoDB基本使用

成功启动MongoDB后,再打开一个命令行窗口输入mongo,就可以进行数据库的一些操作。

输入help可以看到基本操作命令:
show dbs:显示数据库列表
show collections:显示当前数据库中的集合(类似关系数据库中的表)
show users:显示用户

use <db name>:切换当前数据库,这和MS-SQL里面的意思一样
db.help():显示数据库操作命令,里面有很多的命令
db.foo.help():显示集合操作命令,同样有很多的命令,foo指的是当前数据库下,一个叫foo的集合,并非真正意义上的命令
db.foo.find():对于当前数据库中的foo集合进行数据查找(由于没有条件,会列出所有数据)
db.foo.find( { a : 1 } ):对于当前数据库中的foo集合进行查找,条件是数据中有一个属性叫a,且a的值为1

MongoDB没有创建数据库的命令,但有类似的命令。

如:如果你想创建一个“myTest”的数据库,先运行use myTest命令,之后就做一些操作(如:db.createCollection(‘user’)),这样就可以创建一个名叫“myTest”的数据库。

数据库常用命令

1、Help查看命令提示

help

db.help();

db.yourColl.help();

db.youColl.find().help();

rs.help();

2、切换/创建数据库

use yourDB; 当创建一个集合(table)的时候会自动创建当前数据库

3、查询所有数据库

show dbs;

4、删除当前使用数据库

db.dropDatabase();

5、从指定主机上克隆数据库

db.cloneDatabase(“127.0.0.1”); 将指定机器上的数据库的数据克隆到当前数据库

6、从指定的机器上复制指定数据库数据到某个数据库

db.copyDatabase(“mydb”, “temp”, “127.0.0.1”);将本机的mydb的数据复制到temp数据库中

7、修复当前数据库

db.repairDatabase();

8、查看当前使用的数据库

db.getName();

db; db和getName方法是一样的效果,都可以查询当前使用的数据库

9、显示当前db状态

db.stats();

10、当前db版本

db.version();

11、查看当前db的链接机器地址

db.getMongo();

Collection聚集集合

1、创建一个聚集集合(table)

db.createCollection(“collName”, {size: 20, capped: 5, max: 100});

2、得到指定名称的聚集集合(table)

db.getCollection(“account”);

3、得到当前db的所有聚集集合

db.getCollectionNames();

4、显示当前db所有聚集索引的状态

db.printCollectionStats();

用户相关

1、添加一个用户

db.addUser(“name”);

db.addUser(“userName”, “pwd123”, true); 添加用户、设置密码、是否只读

2、数据库认证、安全模式

db.auth(“userName”, “123123”);

3、显示当前所有用户

show users;

4、删除用户

db.removeUser(“userName”);

其他
1、查询之前的错误信息
db.getPrevError();
2、清除错误记录
db.resetError();

查看聚集集合基本信息
1、查看帮助 db.yourColl.help();
2、查询当前集合的数据条数 db.yourColl.count();
3、查看数据空间大小 db.userInfo.dataSize();
4、得到当前聚集集合所在的db db.userInfo.getDB();
5、得到当前聚集的状态 db.userInfo.stats();
6、得到聚集集合总大小 db.userInfo.totalSize();
7、聚集集合储存空间大小 db.userInfo.storageSize();
8、Shard版本信息 db.userInfo.getShardVersion()
9、聚集集合重命名 db.userInfo.renameCollection(“users”); 将userInfo重命名为users
10、删除当前聚集集合 db.userInfo.drop();
聚集集合查询

1、查询所有记录
db.userInfo.find();
相当于:select* from userInfo;
默认每页显示20条记录,当显示不下的情况下,可以用it迭代命令查询下一页数据。注意:键入it命令不能带“;”
但是你可以设置每页显示数据的大小,用DBQuery.shellBatchSize= 50;这样每页就显示50条记录了。

2、查询去掉后的当前聚集集合中的某列的重复数据
db.userInfo.distinct(“name”);
会过滤掉name中的相同数据
相当于:select distict name from userInfo;

3、查询age = 22的记录
db.userInfo.find({“age”: 22});
相当于: select * from userInfo where age = 22;

4、查询age > 22的记录
db.userInfo.find({age: {$gt: 22}});
相当于:select * from userInfo where age >22;

5、查询age < 22的记录
db.userInfo.find({age: {$lt: 22}});
相当于:select * from userInfo where age <22;

6、查询age >= 25的记录
db.userInfo.find({age: {$gte: 25}});
相当于:select * from userInfo where age >= 25;

7、查询age <= 25的记录
db.userInfo.find({age: {$lte: 25}});

8、查询age >= 23 并且 age <= 26
db.userInfo.find({age: {$gte: 23, $lte: 26}});

9、查询name中包含 mongo的数据
db.userInfo.find({name: /mongo/});
//相当于%%
select * from userInfo where name like ‘%mongo%’;

10、查询name中以mongo开头的
db.userInfo.find({name: /^mongo/});
select * from userInfo where name like ‘mongo%’;

11、查询指定列name、age数据
db.userInfo.find({}, {name: 1, age: 1});
相当于:select name, age from userInfo;
当然name也可以用true或false,当用ture的情况下河name:1效果一样,如果用false就是排除name,显示name以外的列信息。

12、查询指定列name、age数据, age > 25
db.userInfo.find({age: {$gt: 25}}, {name: 1, age: 1});
相当于:select name, age from userInfo where age >25;

13、按照年龄排序
升序:db.userInfo.find().sort({age: 1});
降序:db.userInfo.find().sort({age: -1});

14、查询name = zhangsan, age = 22的数据
db.userInfo.find({name: ‘zhangsan’, age: 22});
相当于:select * from userInfo where name = ‘zhangsan’ and age = ‘22’;

15、查询前5条数据
db.userInfo.find().limit(5);
相当于:selecttop 5 * from userInfo;

16、查询10条以后的数据
db.userInfo.find().skip(10);
相当于:select * from userInfo where id not in (
selecttop 10 * from userInfo
);

17、查询在5-10之间的数据
db.userInfo.find().limit(10).skip(5);
可用于分页,limit是pageSize,skip是第几页*pageSize

18、or与 查询
db.userInfo.find({$or: [{age: 22}, {age: 25}]});
相当于:select * from userInfo where age = 22 or age = 25;

19、查询第一条数据
db.userInfo.findOne();
相当于:selecttop 1 * from userInfo;
db.userInfo.find().limit(1);

20、查询某个结果集的记录条数
db.userInfo.find({age: {$gte: 25}}).count();
相当于:select count(*) from userInfo where age >= 20;

21、按照某列进行排序
db.userInfo.find({sex: {$exists: true}}).count();
相当于:select count(sex) from userInfo;
索引
1、创建索引
db.userInfo.ensureIndex({name: 1});
db.userInfo.ensureIndex({name: 1, ts: -1});

2、查询当前聚集集合所有索引
db.userInfo.getIndexes();

3、查看总索引记录大小
db.userInfo.totalIndexSize();

4、读取当前集合的所有index信息
db.users.reIndex();

5、删除指定索引
db.users.dropIndex(“name_1”);

6、删除所有索引索引
db.users.dropIndexes();
修改、添加、删除集合数据

1、添加
db.users.save({name: ‘zhangsan’, age: 25, sex: true});
添加的数据的数据列,没有固定,根据添加的数据为准

2、修改
db.users.update({age: 25}, {$set: {name: ‘changeName’}}, false, true);
相当于:update users set name = ‘changeName’ where age = 25;

db.users.update({name: ‘Lisi’}, {$inc: {age: 50}}, false, true);
相当于:update users set age = age + 50 where name = ‘Lisi’;

db.users.update({name: ‘Lisi’}, {$inc: {age: 50}, $set: {name: ‘hoho’}}, false, true);
相当于:update users set age = age + 50, name = ‘hoho’ where name = ‘Lisi’;

3、删除
db.users.remove({age: 132});

4、查询修改删除
db.users.findAndModify({
query: {age: {$gte: 25}},
sort: {age: -1},
update: {$set: {name: ‘a2’}, $inc: {age: 2}},
remove: true
});

db.runCommand({ findandmodify : “users”,
query: {age: {$gte: 25}},
sort: {age: -1},
update: {$set: {name: ‘a2’}, $inc: {age: 2}},
remove: true
});
update 或 remove 其中一个是必须的参数; 其他参数可选。

参数

详解

默认值

query

查询过滤条件

{}

sort

如果多个文档符合查询过滤条件,将以该参数指定的排列方式选择出排在首位的对象,该对象将被操作

{}

remove

若为true,被选中对象将在返回前被删除

N/A

update

一个 修改器对象

N/A

new

若为true,将返回修改后的对象而不是原始对象。在删除操作中,该参数被忽略。

false

fields

参见Retrieving a Subset of Fields (1.5.0+)

All fields

upsert

创建新对象若查询结果为空。 示例 (1.5.4+)

false

语句块操作
1、简单Hello World
print(“Hello World!”);
这种写法调用了print函数,和直接写入”Hello World!”的效果是一样的;

2、将一个对象转换成json
tojson(new Object());
tojson(new Object(‘a’));

3、循环添加数据
> for (var i = 0; i < 30; i++) {
… db.users.save({name: “u_” + i, age: 22 + i, sex: i % 2});
… };
这样就循环添加了30条数据,同样也可以省略括号的写法
> for (var i = 0; i < 30; i++) db.users.save({name: “u_” + i, age: 22 + i, sex: i % 2});
也是可以的,当你用db.users.find()查询的时候,显示多条数据而无法一页显示的情况下,可以用it查看下一页的信息;

4、find 游标查询
>var cursor = db.users.find();
> while (cursor.hasNext()) {
printjson(cursor.next());
}
这样就查询所有的users信息,同样可以这样写
var cursor = db.users.find();
while (cursor.hasNext()) { printjson(cursor.next); }
同样可以省略{}号

5、forEach迭代循环
db.users.find().forEach(printjson);
forEach中必须传递一个函数来处理每条迭代的数据信息

6、将find游标当数组处理
var cursor = db.users.find();
cursor[4];
取得下标索引为4的那条数据
既然可以当做数组处理,那么就可以获得它的长度:cursor.length();或者cursor.count();
那样我们也可以用循环显示数据
for (var i = 0, len = c.length(); i < len; i++) printjson(c[i]);

7、将find游标转换成数组
> var arr = db.users.find().toArray();
> printjson(arr[2]);
用toArray方法将其转换为数组

8、定制我们自己的查询结果
只显示age <= 28的并且只显示age这列数据
db.users.find({age: {$lte: 28}}, {age: 1}).forEach(printjson);
db.users.find({age: {$lte: 28}}, {age: true}).forEach(printjson);
排除age的列
db.users.find({age: {$lte: 28}}, {age: false}).forEach(printjson);

9、forEach传递函数显示信息
db.things.find({x:4}).forEach(function(x) {print(tojson(x));});

PhpStorm配置XDebug调试PHP

1 PHP配置

首先需要配置PHP,也就是php开启了xdebug拓展.

2 配置 XDebug

路径:File > Settings > Languages & Frameworks > PHP > Debug

phpstrom-debug-02.png

3 配置 Server

路径:File SettingsLanguages & Frameworks PHPServers

phpstrom-debug-01.png

其中,Host 是调试时浏览器访问的域名。

注意:如果所谓的“远程服务器”就在本地的话,就不需要勾选“Use path mappings(select if the servers is remote or symlinks are used)”

4 设置调试项

选择菜单 Run Edit Configurations,弹出“Run/Debug Configrations”对话框:

phpstrom-debug-03.png

phpstrom-debug-04.png

5 开始调试页面

Shift + F9,或菜单选择 Run > Debug 调试名称,开启调试。

phpstrom-debug-06.png

特别说明下:

如果选择了 Run > Start Listening for PHP Debug connections,则PHPStorm会监听浏览器,如果浏览器访问第4步的”Start Url“,那么PHPStorm会自动跳转到断点处。点击调试按钮,一步一步调试吧!

常用的几个快捷键:

  • F7:步入
  • F8:跳过
  • Shift + F8:步出
  • Alt + F9:调到光标处

所有快捷键最好从 Run 菜单下查看。

人生的悲剧只有两种:一种是没有得到自己想要的东西,另一种是得到自己想要的东西。
                                —王尔德

标签

打赏