- 博客(5)
- 收藏
- 关注
RSS订阅原创 高效读写DB---目标
最近的工作需要频繁的读写数据库，即使我们用了 redis做缓存，这样的话，我们减少了对数据库的读，但没有减少对数据库的写。我想要减少对数据库的写操作，这样可以减少对数据库的压力。所以决定实现一个DBCache.主要作用：缓存部分数据 根据需求，我们可以按照LRU算法，来在DBCache缓存活跃用户数据，这样有两个作用：第一，当用户来读数据的话，我们可以直接，从DBCache的内存缓
2013-03-20 19:03:10
672
原创 构建通用还是专一型系统
所谓通用就是在什么地方，什么时间都能共用的东西（自己定义）经常在开发讨论的过程中，会遇到一些比较特殊的问题。例如我们在用一个开源软件memcached或者redis，会遇到一些很特别的问题，而这个问题对系统的整体性能影响很大，(具体我就不说了，涉及到公司的业务处理），我的原则是我们不能按照现有的策略去是用redis,或者memcached，既然是开源的我们能拿到源码，我们开源在源码中做少许的改
2013-03-18 18:15:43
544
原创 数据控制层实现
接着上一篇的设计，初步构想的实现如下：综述： 数据控制层，主要是负责app(应用层）跟数据层的交互。 目的：减少整个服务器组的耦合度，以是应用层的逻辑与数据分开，最大限度的提高应用层服务的吞吐量。设计原则：最大限度的实现异步，并发处理。屏蔽应用层与数据层的交互细节。程序分三层：网络层，逻辑层，数据交互层网络层：采用epoll做客户端请求的网络处理。这一层主要
2013-03-17 22:46:25
1146
原创 redis 集群设计一种方案
最近，在做一个管理2亿用户数据的平台方案，根据我们业务的需求，采用http协议，这样很自然地，我们就是用了webserver, nginx+fast_cgi ,后端缓存我们选择了redis.但对于2亿的用户处理，我们的缓存不能是一两台就能够的，最后我们决定使用8个redis来缓存我们目前的数据。这样问题就来了：服务器组耦合度很大，不利于开发，维护， 我们的应用进程要去访
2013-03-14 13:16:39
715
原创 redis应用小技巧
前两天在跟同事讨论交互协议时间，由于我们的架构技术上采用的是http协议，对每个请求，应用程序要跟redis交互两次，一次去取用户登录的session,拿到本地应用逻辑验证通过后再做下面的逻辑处理。对于这种用法，我本人是很反对这种交互方式的，没有必要没个请求逻辑都要去redis请求两次， 我认为至少我们有两种方法来解决这个问题（要请求两次）的:1 我们可以在请求的包里加一段lua脚本,
2013-03-07 22:51:51
784
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人