事实上,Redis的一个重要特性就是它并非通常意义上的数据库,虽然称之为数据库是因为它可以为你存储和维护数据,但它并不像关系数据库那样提供任何的SQL方言。不过不用担心,Redis并不是吞噬数据的黑洞,它只是不支持SQL及相关功能,但却提供了稳健的协议用于与之交互。
在Redis中,没有数据表的概念,也无须关心select、join、view等 *** 作或功能,同时也不提供类似于int或varchar的数据字段。你面对的将是相对原始的数据集合及数据类型。
探索之二:Available datatypes
下面我们深入看下这个奇怪的数据库是如何工作的。如上所见,Redis是基于key-value范式存储数据,所以先来重点看下"key"的概念。
key本质上就是简单的字符串,诸如"username"、"password"等。在定义key时,除了不能使用空格,你可以随意的使用普通的字符、数字等,像".",":","_"等在定义key时都能正常使用,所以像"user_name", "user:123:age", "user:123:username"都是不错的key的定义方式。
不像RDBMS中的字段名称,这里的key是Redis中的重要组成部分,所以我们必须在处理key时多加小心。在下面的讲述中,Redis并没有table的概念,所以像"SELECT username from users WHERE user_id=123"这种简单任务都只能换种方式实现,为了达到这种目的,在Redis上,一种方式是通过key "user:123:username"来获取结果value。如你所见,key的定义中携带了神秘信息(像user ids)。在Redis中,key的重要性可见一斑。(其他key-value数据库中key的地位也是如此。)
两种方式都存在。一种是对数据时效性要求高的,会先写入redis,这样读取的时候就能读取到最新的数据,然后再把数据同步到mysql中。
一种是先写入mysql,然后再写入redis。这样实现方便,每次只要redis不存在,就从mysql获取数据即可,缺点也明显,有一定的数据延迟。数据一致性要求不高的场合可以使用这种方式。
redis读写分离主要是为了解决单点故障设计的,有了主从复制,当主节点宕机的时候,哨兵节点会选择从节点当主节点,保证服务的可用性。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)