1. Redis入门教程 -- 我们开始学习Redis的时候,可以先按照这个教程看一遍,教程中包括Redis介绍,环境配置等
  2. Redis命令参考 -- 比较好用和详细的Redis命令参考手册
  3. Redis中文官网 -- 资料比较全,有常用命令,文档等等
  4. Redis中文文档 -- Redis中文文档,这个上面主要用来查看Redis命令
  5. Redis有效时间设置及时间过期处理 -- Redis 自动删除 专题学习文章
  6. Redis持久化 -- Redis 持久化 专题学习文章
  7. 深入学习Redis(1):Redis内存模型 -- Redis 内存 专题学习文章,此文章中还涉及持久化等,质量较高的Blog
  8. 理解Redis的内存 -- Redis 内存 专题学习文章,质量较高的Blog
  9. Redis 设计与实现 -- 书籍链接,部分章节不可见
  10. Redis特性和应用场景 -- 不同数据结构的不同命令写的比较清楚,最后有几个应用场景写的不错
  11. RedisDesktopManager -- 可视化工具
  12. Type-safe Redis client for Golang -- go-redis,golang的redis库

最近在进行技术方案设计的时候,经常会牵扯到DB的选型(redis和MySQL),由于对数据库不熟悉,请教了学东大佬,建议如下:
如果说最终数据要落到mysql中,就先没必要搞任何形式的缓存。
如果直接把redis+持久化当做数据库来用,那么考虑下后续业务的拓展,如果能应对需求变化,直接用redis也是可以的。

redis + mysql 架构的方式,常见有一下两种:

  1. mysql作为主库,redis作为缓存
  2. redis作为主库,mysql作为冷备库
    我这边用的主要是第一种方式:两者的关联是数据一致性,可被动同步和主动同步。数据来源最好是先mysql->redis。缓存更新触发可以是 被动更新/主动更新。

用Redis作Mysql数据库缓存,必须解决2个问题。首先,应该确定用何种数据结构存储来自Mysql的数据;在确定数据结构之后,还要考虑用什么标识作为该数据结构的键。
直观上看,Mysql中的数据都是按表存储的;更微观地看,这些表都是按行存储的。每执行一次select查询,Mysql都会返回一个结果集,这个结果集由若干行组成。所以,一个自然而然的想法就是在Redis中找到一种对应于Mysql行的数据结构。Redis中提供了五种基本数据结构,即字符串(string)、列表(list)、哈希(hash)、集合(set)和有序集合(sorted set)。经过调研,发现适合存储行的数据结构有两种,即string和hash。
要把Mysql的行数据存入string,首先需要对行数据进行格式化。事实上,结果集的每一行都可以看做若干由字段名和其对应值组成的键值对集合。这种键值对结构很容易让我们想起Json格式。因此,这里选用Json格式作为结果集每一行的格式化模板。根据这一想法,我们可以实现将结果集格式化为若干Json对象,并将Json对象转化为字符串存入Redis的代码。

参考:
浅谈Redis数据库的键值设计
如何将数据库中表转化到redis中
基于内存,redis,mysql的高速游戏数据服务器设计架构
缓存更新的套路
MySQL 查询缓存
热点数据缓存技术
mysql 缓存机制
初学Redis(1)——认识Redis
初学Redis(2)——用Redis作为Mysql数据库的缓存
初学Redis(3)——用Redis作为Mysql数据库的缓存
初学Redis(4)——简单实现Redis缓存中的排序功能

一般对于服务依赖的保护主要有3种解决方案:
(1)熔断模式
(2)隔离模式
(3)限流模式
熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,不再调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。

熔断(Circuit Breaker)模式:会处理一些需要一定时间来重连远程服务和远端资源的错误。该模式可以提高一个应用的稳定性和弹性。熔断模式可以防止应用重复的尝试调用容易失败的操作,当熔断模式判断错误会持续的时候,它会令操作不再持续等待,以免继续浪费CPU资源。当然,熔断模式也令应用本身可以发现错误有没有被修复。如果发生的问题已经被修复了,应用可以重新尝试去调用服务。
熔断模式可以按照:关闭、打开、半开,三个状态来模仿一个断路器的实现,如下图所示,熔断器模式定义了熔断器开关相互转换的逻辑:
1111.jpg
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的(PS:服务的健康状况 = 请求失败数 / 请求总数)。
关闭:应用的请求已经路由到了这个操作。代理应该维护最近一段时间的错误信息,如果调用操作失败,那么大力增加这个错误信息的数量。如果这个错误数量超过给定时间的阈值,代理进入到打开状态。这个时候,代理启动一个超时的Timer,当Timer过期了,代理则进入半开状态。超时Timer的目的是为了给系统一段时间来自我修复之前碰到的问题。
打开:令可能失败的外部调用操作立刻失败,所有的外部调用直接抛异常给应用。
半开:只有一定数量的应用请求可以进行操作的调用。如果这些请求成功了,那么就假定之前发成的错误已经被系统自动修复了,而Circuit-Breaker转换成关闭状态(同时重置错误计数器)。如果任何请求失败了,那么Circuit-Breaker会假定错误仍然在存在,Circuit-Breaker会重新转换成打开状态,并重启超时Timer给系统更多的时间来自我修复错误。

何时使用熔断(Circuit-Breaker)模式:当需要阻止应用不断尝试调用远端服务或者访问共享资源,并且这些请求很容易失败的时候使用Circuit-Breaker模式很合适。

什么场景不适合使用该模式:

当用来处理访问本地资源,比如内存中的数据结构的时候,不适合使用。在这种场景下,Circuit-Breaker只会给应用带来额外的负担。
将Circuit-Breaker作为处理应用中的业务逻辑中的异常处理的一部分也是不合适的。
参考文章:
大话分布式架构(五)- 熔断隔离
大话分布式架构(一)
架构必经之路2 - 熔断机制

在进行产品演示的时候,发现有一个头像框出现了锯齿,这个头像框控件是: ImageView。
于是就从Cocos引擎上找问题,如下:
由于一些特定的原因,程序并没有使用plist方式打包资源,而现在使用的是零散的小图片。在运行时,发现会出现某些图片显示模糊的情况。找到的原因如下:

纹理在初始化的时候默认调用了setAntiAliasTexParameters接口,而该接口设置GL_TEXTURE_MIN_FILTER和GL_TEXTURE_MAG_FILTER为GL_LINEAR。而使用GL_LINEAR渲染时,如果文理的像素点和显示区域的坐标不能一一对应(例如放大,缩小,或者显示位置为浮点数),就会使用附近的四个像素(2*2, 2D显示)做颜色混合,这样会使图片看上去模糊。
解决办法:
根据上述分析,可以用如下几种办法:
1、调用Texture的setAliasTexParameters接口,副作用在放大或缩小时会导致锯齿严重,而且如果显示位置为浮点数的话,会导致最后一行(一列)像素被截掉。
如果是cc.Sprite调用:

Sprite:getTexture():setAliasTexParameters()
如果是Widget控件使用呢 继承Widget接口的ImageView,调用:
ImageView:getVirtualRenderer():getSprite():getTexture():setAliasTexParameters()

如果是BUTTON需要去源码中找相应接口
2、不要使用图片分辨率为奇数的图片,因为使用奇数的图片,如果设置AnchorPoint为(0.5f, 0.5f), 即使setPosition()传入整数参数,也会导致图片的显示坐标为小数。
3、如果一定要使用分辨率为奇数的图片,锚点设为(0.0f, 0.0f), 这样可以保证只要setPosition()传入的是整数(注意父控件的位置也不能是浮点数)就不会有显示问题。

我是采用了方案1和方案3,但是还是不行。 于是乎,我打开了美术给的原图,发现原图就存在锯齿。 找了美术,美术这边的解释是图片太清晰就会存在锯齿问题,需要进行模糊化。 经过模糊化处理后解决。

参考文章:
https://blog.csdn.net/yuanhong2910/article/details/7506593
https://www.jianshu.com/p/0d1bbb29e63d