在Web服务开发中，服务端缓存是服务实现中所常常采用的一种提高服务性能的方法。其通过记录某部分计算结果来尝试避免再次执行得到该结果所需要的复杂计算，从而提高了服务的运行效率。
除了能够提高服务的运行效率之外，服务端缓存还常常用来提高服务的扩展性。因此一些大规模的Web应用，如Facebook，常常构建一个庞大的服务端缓存。而它们所最常使用的就是Memcached。
在本文中，我们就将对Memcached进行简单地介绍。
Memcached简介
在介绍Memcached之前，让我们首先通过一个示例了解什么是服务端缓存。
相信大家都玩过一些网络联机游戏吧。在我那个年代（03年左右），这些游戏常常添加了对战功能，并提供了天梯来显示具有最优秀战绩的玩家以及当前玩家在天梯系统中的排名。这是游戏开发商所常常采用的一种聚拢玩家人气的手段。而希望在游戏中证明自己的玩家则会由此激发斗志，进而花费更多时间来在天梯中取得更好的成绩。
就天梯系统来说，其最主要的功能就是为玩家提供天梯排名的信息，而并不允许玩家对该系统中所记录的数据作任何修改。这样设定的结果就是，整个天梯系统的读操作居多，而写操作很少。反过来，由于一个游戏中的玩家可能有上千万甚至上亿人，而且在线人数常常达到上万人，因此对天梯的访问也会是非常频繁的。这样的话，即使每秒钟只有10个人访问天梯中的排名，对这上亿个玩家的天梯排名进行读取及排序也是一件非常消耗性能的事情。
一个自然而然的想法就是：在对天梯排名进行一次计算后，我们在服务端将该天梯排名缓存起来，并在其它玩家访问的时候直接返回该缓存中所记录的结果。而在一定时间段之后，如一个小时，我们再对缓存中的数据进行更新。这样我们就不再需要每个小时执行成千上万次的天梯排名计算了。
而这就是服务端缓存所提供的最重要功能。其既可以提高单个请求的响应速度，又可以降低服务层及数据库层的压力。除此之外，多个服务实例都可以读取该服务端缓存所缓存的信息，因此我们也不再需要担心这些数据在各个服务实例中都保存了一份进而需要彼此同步的问题，也即是提高了扩展性。
而Memcached就是一个使用了BSD许可的服务端缓存实现。但是与其它服务端缓存实现不同的是，其主要由两部分组成：独立运行的Memcached服务实例，以及用于访问这些服务实例的客户端。因此相较于普通服务端缓存实现中各个缓存都运行在服务实例之上的情况，Memcached服务实例则是在服务实例之外独立运行的：
从上图中可以看出，由于Memcached缓存实例是独立于各个应用服务器实例运行的，因此应用服务实例可以访问任意的缓存实例。而传统的缓存则与特定的应用实例绑定，因此每个应用实例将只能访问特定的缓存。这种绑定一方面会导致整个应用所能够访问的缓存容量变得很小，另一方面也可能导致不同的缓存实例中存在着冗余的数据，从而降低了缓存系统的整体效率。
在运行时，Memcached服务实例只需要消耗非常少的CPU资源，却需要使用大量的内存。因此在决定如何组织您的服务端缓存结构之前，您首先需要搞清当前服务中各个服务实例的负载情况。如果一个服务器的CPU使用率非常高，却存在着非常多的空余内存，那么我们就完全可以在其上运行一个Memcached实例。而如果当前服务中的所有服务实例都没有过多的空余内存，那么我们就需要使用一系列独立的服务实例来搭建服务端缓存。一个大型服务常常拥有上百个Memcached实例。而在这上百个Memcached实例中所存储的数据则不尽相同。由于这种数据的异构性，我们需要在访问由Memcached所记录的信息之前决定在该服务端缓存系统中到底由哪个Memcached实例记录了我们所想要访问的数据：
如上图所示，用户需要通过一个Memcached客户端来完成对缓存服务所记录信息的访问。该客户端知道服务端缓存系统中所包含的所有Memcached服务实例。在需要访问具有特定键值的数据时，该客户端内部会根据所需要读取的数据的键值，如“foo”，以及当前Memcached缓存服务的配置来计算相应的哈希值，以决定到底是哪个Memcached实例记录了用户所需要访问的信息。在决定记录了所需要信息的Memcached实例之后，Memcached客户端将从配置中读取该Memcached服务实例所在地址，并向该Memcached实例发送数据访问请求，以从该Memcached实例中读取具有键值“foo”的信息。在各个论坛的讨论中，这被称为是Memcached的两阶段哈希（Two-stage hash）。
而对数据的记录也使用了类似的流程：假设用户希望通过服务端缓存记录数据“bar”，并为其指定键值“foo”。那么Memcached客户端将首先对用户所赋予的键值“foo”及当前服务端缓存所记录的可用服务实例个数执行哈希计算，并根据哈希计算结果来决定存储该数据的Memcached服务实例。接下来，客户端就会向该实例发送请求，以在其中记录具有键值“foo”的数据“bar”。
这样做的好处则在于，每个Memcached服务实例都是独立的，而彼此之间并没有任何交互。在这种情况下，我们可以省略很多复杂的功能逻辑，如各个节点之间的数据同步以及结点之间消息的广播等等。这种轻量级的架构可以简化很多操作。如在一个节点失效的时候，我们仅仅需要使用一个新的Memcached节点替代老节点即可。而在对缓存进行扩容的时候，我们也只需要添加额外的服务并修改客户端配置。
这些记录在服务端缓存中的数据是全局可见的。也就是说，一旦在Memcached服务端缓存中成功添加了一条新的记录，那么其它使用该缓存服务的应用实例将同样可以访问该记录：
在Memcached中，每条记录都由四部分组成：记录的键，有效期，一系列可选的标记以及表示记录内容的数据。由于记录内容的数据中并不包含任何数据结构，因此我们在Memcached中所记录的数据需要是经过序列化之后的表示。
内存管理
在使用缓存时，我们不得不考虑的一个问题就是如何对这些缓存数据的生存期进行管理。这其中包括如何使一个记录在缓存中的数据过期，如何在缓存空间不够时执行数据的替换等。因此在本节中，我们将对Memcached的内存管理机制进行介绍。
首先我们来看一看Memcached的内存管理模型。通常情况下，一个内存管理算法所最需要考虑的问题就是内存的碎片化（Fragmentation）：在长时间地分配及回收之后，被系统所使用的内存将趋向于散落在不连续的空间中。这使得系统很难找到连续内存空间，一方面增大了内存分配失败的概率，另一方面也使得内存分配工作变得更为复杂，降低了运行效率。
为了解决这个问题，Memcached使用了一种叫Slab的结构。在该分配算法中，内存将按照1MB的大小划分为页，而该页内存则会继续被分割为一系列具有相同大小的内存块：
因此Memcached并不是直接根据需要记录的数据的大小来直接分配相应大小的内存。在一条新的记录到来时，Memcached会首先检查该记录的大小，并根据记录的大小选择记录所需要存储到的Slab类型。接下来，Memcached就会检查其内部所包含的该类型Slab。如果这些Slab中有空余的块，那么Memcached就会使用该块记录该条信息。如果已经没有Slab拥有空闲的具有合适大小的块，那么Memcached就会创建一个新的页，并将该页按照目标Slab的类型进行划分。
一个需要考虑的特殊情况就是对记录的更新。在对一个记录进行更新的时候，记录的大小可能会发生变化。在这种情况下，其所对应的Slab类型也可能会发生变化。因此在更新时，记录在内存中的位置可能会发生变化。只不过从用户的角度来说，这并不可见。
Memcached使用这种方式来分配内存的好处则在于，其可以降低由于记录的多次读写而导致的碎片化。反过来，由于Memcached是根据记录的大小选择需要插入到的块类型，因此为每个记录所分配的块的大小常常大于该记录所实际需要的内存大小，进而造成了内存的浪费。当然，您可以通过Memcached的配置文件来指定各个块的大小，从而尽可能地减少内存的浪费。
但是需要注意的是，由于默认情况下Memcached中每页的大小为1MB，因此其单个块最大为1MB。除此之外，Memcached还限制每个数据所对应的键的长度不能超过250个字节。
一般来说，Slab中各个块的大小以及块大小的递增倍数可能会对记录所载位置的选择及内存利用率有很大的影响。例如在当前的实现下，各个Slab中块的大小默认情况下是按照1.25倍的方式来递增的。也就是说，在一个Memcached实例中，某种类型Slab所提供的块的大小是80K，而提供稍大一点空间的Slab类型所提供的块的大小就将是100K。如果现在我们需要插入一条81K的记录，那么Memcached就会选择具有100K块大小的Slab，并尝试找到一个具有空闲块的Slab以存入该记录。
同时您也需要注意到，我们使用的是100K块大小的Slab来记录具有81K大小的数据，因此记录该数据所导致的内存浪费是19K，即19%的浪费。而在需要存储的各条记录的大小平均分布的情况下，这种内存浪费的幅度也在9%左右。该幅度实际上取决于我们刚刚提到的各个Slab中块大小的递增倍数。在Memcached的初始实现中，各个Slab块的递增倍数在默认情况下是2，而不是现在的1.25，从而导致了平均25%左右的内存浪费。而在今后的各个版本中，该递增倍数可能还会发生变化，以优化Memcached的实际性能。
如果您一旦知道了您所需要缓存的数据的特征，如通常情况下数据的大小以及各个数据的差异幅度，那么您就可以根据这些数据的特征来设置上面所提到的各个参数。如果数据在通常情况下都比较小，那么我们就需要将最小块的大小调整得小一些。如果数据的大小变动不是很大，那么我们可以将块大小的递增倍数设置得小一些，从而使得各个块的大小尽量地贴近需要存储的数据，以提高内存的利用率。
还有一个值得注意的事情就是，由于Memcached在计算到底哪个服务实例记录了具有特定键的数据时并不会考虑用来组成缓存系统中各个服务器的差异性。如果每个服务器上只安装了一个Memcached实例，那么各个Memcached实例所拥有的可用内存将存在着数倍的差异。但是由于各个实例被选中的概率基本相同，因此具有较大内存的Memcached实例将无法被充分利用。我们可以通过在具有较大内存的服务器上部署多个Memcached实例来解决这个问题：
例如上图所展示的缓存系统是由两个服务器组成。这两个服务器中的内存大小并不相同。第一个服务器的内存大小为32G，而第二个服务器的内存大小仅仅有8G。为了能够充分利用这两个服务器的内存，我们在具有32G内存的服务器上部署了4个Memcached实例，而在只有8G内存的服务器上部署了1个Memcached实例。在这种情况下，32G内存服务器上的4个Memcached实例将总共得到4倍于8G服务器所得到的负载，从而充分地利用了32G内存服务器上的内存。
当然，由于缓存系统拥有有限的资源，因此其会在某一时刻被服务所产生的数据填满。如果此时缓存系统再次接收到一个缓存数据的请求，那么它就会根据LRU（Least recently used）算法以及数据的过期时间来决定需要从缓存系统中移除的数据。而Memcached所使用的过期算法比较特殊，又被称为延迟过期（Lazy expiration）：当用户从Memcached实例中读取数据的时候，其将首先通过配置中所设置的过期时间来决定该数据是否过期。如果是，那么在下一次写入数据却没有足够空间的时候，Memcached会选择该过期数据所在的内存块作为新数据的目标地址。如果在写入时没有相应的记录被标记为过期，那么LRU算法才被执行，从而找到最久没有被使用的需要被替
Android图像格式类及图像转换方法介绍 一款软件的开发和图像密切相关，特别是移动应用程序，在视觉效果等方面是至关重要的，因为这直接关系到用户的体验效果。在Android程序开发的过程中，了解存在哪些图像格式类（ImageFormat、PixelFormat及BitmapConfig等）及图像（JPG、PNG及BMP等）的转换方法，对以后的开发多多少少会有些帮助。
关于图像格式类，介绍以下三个：ImageFormat、PixelFormat及BitmapConfig。
1、ImageFormat(android.graphics.ImageFormat)，格式参数有以下几种：
int JPEG ，Encoded formats，常量值： 256 (0x00000100)
int NV16，YCbCr format, used for video，16 (0x00000010)
int NV21，YCrCb format used for images, which uses the NV21 encoding format，常量值： 17 (0x00000011)
int RGB_565，RGB format used for pictures encoded as RGB_565，常量值： 4 (0x00000004)
int UNKNOWN， 常量值：0 (0x00000000)
int YUY2，YCbCr format used for images，which uses YUYV (YUY2) encoding format，20 (0x00000014)
int YV12，Android YUV format，This format is exposed to software decoders and applications，
YV12 is a 4:2:0 YCrCb planar format comprised of a WxH Y plane followed by (W/2) x (H/2) Cr and Cb planes
解释总是英文的最通俗易懂，这里就不献丑翻译了。用法举例，在构建ImageReader类的对象时，会用到ImageFormat类的图像格式对象。如
imageReader对象表示其缓存中最多存在宽高分别为width和height、RGB_565格式的图像流两帧。
在需求中用哪一种图像格式，要视实际情况而定，后面的类似。
2、PixelFormat(android.graphics.PixelFormat)，格式参数有以下几种：
int A_8，常量值：8 (0x00000008)
int JPEG，常量值：256 (0x00000100)，constant，已声明不赞成使用，use ImageFormat.JPEG instead.
int LA_88，常量值：10 (0x0000000a)
int L_8， 常量值：9 (0x00000009)
int OPAQUE，常量值： -1 (0xffffffff)，System chooses an opaque format (no alpha bits required)
int RGBA_4444，常量值：7 (0x00000007)
int RGBA_5551，常量值：6 (0x00000006)
int RGBA_8888，常量值：1 (0x00000001)
int RGBX_8888，常量值：2 (0x00000002)
int RGB_332，常量值：11 (0x0000000b)
int RGB_565，常量值：4 (0x00000004)
int RGB_888，常量值：3 (0x00000003)
int TRANSLUCENT，常量值： -3 (0xfffffffd)，System chooses a format that supports translucency (many alpha bits)
int TRANSPARENT，常量值：-2 (0xfffffffe)，System chooses a format that supports transparency (at least 1 alpha bit)
int UNKNOWN，常量值： 0 (0x00000000)
int YCbCr_420_SP，常量值：17 (0x00000011)，constant 已声明不赞成使用 use ImageFormat.NV21 instead
int YCbCr_422_I，常量值： 20 (0x00000014)，constant 已声明不赞成使用 use ImageFormat.YUY2 instead
int YCbCr_422_SP，常量值：16 (0x00000010)，constant 已声明不赞成使用 use ImageFormat.NV16 instead
注意，有四种图像格式已被声明不赞成使用，可以用ImaggFormat相对应的格式进行代替。由此可知，两种图像格式之间存在相通之处。用法举例，让窗口实现渐变的效果，如
补充说明：RGBA_8888为android的一种32位颜色格式，R、G、B、A分别用八位表示，Android默认的图像格式是PixelFormat.OPAQUE，其是不带Alpha值的。
3、Bitmap.Config(Android.graphics.Bitmap内部类)
Possible bitmap configurations。A bitmap configuration describes how pixels are stored。This affects the quality (color depth) as well as the ability to display transparent/translucent colors。(官网介绍，大致意思是说：影响一个图片色彩色度显示质量主要看位图配置，显示图片时透明还是半透明)。
ALPHA_8：Each pixel is stored as a single translucency (alpha) channel。（原图的每一个像素以半透明显示）
ARGB_4444：This field was deprecated in API level 13。Because of the poor quality of this configuration, it is advised to use ARGB_8888 instead。（在API13以后就被弃用了，建议使用8888）。
ARGB_8888 ：Each pixel is stored on 4 bytes。 Each channel (RGB and alpha for translucency) is stored with 8 bits of precision (256 possible values) 。This configuration is very flexible and offers the best quality。 It should be used whenever possible。（每个像素占4个字节，每个颜色8位元，反正很清晰，看着很舒服）。
RGB_565：Each pixel is stored on 2 bytes and only the RGB channels are encoded：red is stored with 5 bits of precision (32 possible values)，green is stored with 6 bits of precision (64 possible values) and blue is stored with 5 bits of precision。（这个应该很容易理解了）。
用法举例，构建Bitmap对象时，会用到BitmapConfig类图像格式对象，如：
没有评论:
发表评论