标签归档:redis

RSS feed of redis

最后更新于 .

之前在文章里面有提到过,很多事情,并没有绝对的对错,只是度的问题。而度的衡量又取决于时、势二字。所以当形势逼人的时候,基本就是这件事情非做不可的时候了。

先说下背景,公司的服务器一直用的阿里云,包括mysql、redis也都是买了ECS自己搭建的。这里面有几个原因:

  1. 创业的时候,阿里云只提供mysql的存储,redis的存储还没提供。
  2. 没钱,即时现在去看redis的存储价格也是贵的吓人。

这样自己来搞存储有好处也有坏处。 好处:

  1. 完全可控,比如连接数限制,内存限制,存储限制。还有数据备份的灵活性等等。
  2. 强迫团队服务器研发要有存储运维能力。
  3. 省钱

坏处:

  1. 冷备、热备方案不完善。
  2. 存储运维的成本较高,需要长时间积累。

ok,问题就是这样,接下来再来说一下我们之前的冷备和热备方案。 可以说极其简陋:

  1. mysql、redis每天10点冷备,备份到本地磁盘和阿里云OSS
  2. redis使用rdb落地,每60秒至少有1次写就会触发落地。

这样做的问题其实挺多的,主要几个:

  1. mysql dump的时候会导致游戏卡顿,即使加了 --single-transaction 参数 也仅仅是缓解
  2. 冷备频率过低,真出现问题数据已经太久
  3. 没有热备,风险较大

针对这些问题,我们先做了mysql备份的优化 ...

最后更新于 .

最近在调整游戏的后台架构,之前因为需要快速出产品,所以整个代码都揉成一团,也基本没有做任何分层处理。现在服务器端的开发也开始逐渐招进来,所以打算打算换一套统一的架构,以后做新游戏只要做其中的业务逻辑即可。

其实之前在腾讯的时候,基本不会用到message queue这种,所有的分布式处理都是由自己写c++ server来互相通信的。这样的处理虽然开发量稍微大一点,但是性能和灵活性确实很高。

现在自己在外面做,虽然自己已经封装了一套server的框架出来,但是毕竟还有太多的轮子需要自己制造,所以就想到了之前一直有了解过celery,来看一下这种基于message queue的任务系统能达到什么性能。

RabbitMQ

celery首推的mq是rabbitmq,所以需要先安装一下:

在mac下用brew 安装:

brew install rabbitmq

安装成功之后,即可启动server了。

不过在这之前,我们先把后台管理的插件打开:

rabbitmq-plugins enable rabbitmq_management

之后执行如下命令,启动server:

rabbitmq-server

这个时候就可以通过 http://127.0.0.1:15672/ 来访问后台管理端了,默认的用户名和密码是guest guest,可以自己在页面上修改。截图如下:

NewImage

 

Redis

celery也支持redis作为broker和backend,所以redis也需要安装一下 ...