赶路人儿

我们知道，经度范围是东经180到西经180，纬度范围是南纬90到北纬90，我们设定西经为负，南纬为负，所以地球上的经度范围就是[-180， 180]，纬度范围就是[-90，90]。如果以本初子午线、赤道为界，地球可以分成4个部分。如果纬度范围[-90°, 0°)用二进制0代表，（0°, 90°]用二进制1代表，经度范围[-180°, 0°)用二进制0代表，（0°, 180°]用二进制1代表，那么地球可以分成如下4个部分：如果在小块范围内递归对半划分呢？可以看到，划分的区域更多了，也更精确了。

Redis分布式锁分布式锁在很多场景中是非常有用的原语， 不同的进程必须以独占资源的方式实现资源共享就是一个典型的例子。有很多分布式锁的库和描述怎么实现分布式锁管理器（DLM)的博客,但是每个库的实现方式都不太一样，很多库的实现方式为了简单降低了可靠性，而有的使用了稍微复杂的设计。这个页面试图提供一个使用Redis实现分布式锁的规范算法。我们提出一种算法，叫Redlock,我们认为这种...

在分布式环境中，很多场景，如：秒杀、ID生成... 都需要分布式锁。分布式锁的实现，可以基于redis的setnx，zk的临时节点。。。今天我们介绍一种redis官方推荐的方法——redission。1、pom.xml<dependency> <groupId>org.redisson</groupId> <artifactId&...

Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。它的主要功能有：不时地监控redis是...

Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求。Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案主要分为一下几种：...

maven<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.9.0</version></dependency>&lt

redis从3.0开始支持集群功能。redis集群采用无中心节点方式实现，无需proxy代理，客户端直接与redis集群的每个节点连接，根据同样的hash算法计算出key对应的slot，然后直接在slot对应的redisj节点上执行命令。在redis看来，响应时间是最苛刻的条件，增加一层带来的开销是redis不能接受的。因此，redis实现了客户端对节点的直接访问，为了去中心化，节点之间通过gos...

大家好，给大家介绍一下， 新晋的高性能的 K/V数据库: badger。这是 dgraph.io开发的一款基于 log structured merge (LSM) tree 的 key-value 本地数据库， 使用 Go 开发。事实上，市面上已经有一些知名的基于LSM tree的k/v数据库， 比如 leveldb、goleveldb、rocksdb、boltdb, 可是为什么还要创造...

把表名转换为key前缀, 比如:　tag:第二段放置用于区分key的字段--对应mysql中的主键的列名第三段放置主键值第三段写列名用户表user, 转换为redis的key-value存储useridusernamepasswordemail9Lisi111111lisi@163.com比如:127.0.0.1:6379> set user:userid:9:username lisiO...

我们都知道，业内的所有nosql数据库在存储的时候基本都可以对key设置一个ttl——（time to live），也就是失效时间。这个功能非常有用，特别是在缓存数据的更新，以及一些定时优惠等需求场景来说，更是如此。今天在couchbase上踩到了一个有意思的坑，对某个key设置了一个一年的ttl，当再次获取该key 的时候居然莫名奇妙的小时 了。public static void te

大规模的数据库存储系统中，数据的生命周期管理是很有必要的；从业务角度发现过期数据，数据归档和数据碎片整理等。以MySQL为例，1个运行很久的TB级MySQL实例中，极有可能数百GB的数据，对业务来说是”过期数据”可直接归档后清理。如果不能发现和及时清理，这部分“过期数据”对生产数据库备份资源消耗，占用工作集数据内存(过期数据行可能分散InnoDB的page中)，影响数据还原的RTO等。从成本和运维

摘要：本文使用redis来实现乐观锁，并以秒杀系统为实例来讲解整个过程。本文源码请在这里下载：https://github.com/appleappleapple/DistributeLearning乐观锁      大多数是基于数据版本（version）的记录机制实现的。即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个”version”字

1）下载、解压：[root@centOS1 src]#cd /usr/local/wgethttps://github.com/antirez/redis/archive/2.8.23.tar.gztar -xvzfredis-2.8.23.tar.gz 2）编译、安装：[root@centOS1local]# cd redis-2.8.23[root@centOS

Optimistic locking using check-and-set(乐观锁)乐观锁介绍：watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null

一.Mongodb的安装 环境：linux 64bit版本：2.0.1位置：/opt/mongodb安装步骤：tar –zxvf mongodb-linux-x86_64-2.0.1.tar –C /opt/mongodbmkdir /opt/mongodb/datatouch /opt/mongodb/logs 安装是很简单的，关键是下面的启动的配置。启动

redis提供了INFO这个命令，能够随时监控服务器的状态，只用telnet到对应服务器的端口，执行命令即可：telnet localhost 6379info在输出的信息里面有这几项和缓存的状态比较有关系：keyspace_hits:14414110keyspace_misses:3228654used_memory:433264648expired_keys:1333536e

Redis中有个设置时间过期的功能，即通过setex或者expire实现，目前redis没有针对hash结构提供hsetex（）这样的方法，所以如果想对hash进行expires设置，可以采用下面的方法：redis 127.0.0.1:6379> hset expire:me name tom(integer) 0redis 127.0.0.1:6379> hget expi...

自Redis增加Sentinel集群工具以来，本博主就从未尝试过使用该工具。最近在调研目前主流的Redis集群部署方案，所以详细地看了一遍官方对于Sentinel的介绍并在自己的台式机上完成了三Redis实例+三Sentinel实例的部署，这里做一下简单的总结。    首先，下载安装Redis。目前随Redis 2.8发布的Sentinel版本被antirez称为Sentinel 2，是在

1、使用了jedis客户端，对redis进行了封装，包括：1）使用了redispool获取连接；以及连接的回收；2）常用五种数据结构的常用操作封装；package redis.utils;import java.util.List;import java.util.Map;import java.util.Set;//import org.apache.log4j.Logg

1、计算qps：1）redis发布版本中自带了redis-benchmark性能测试工具，可以使用它计算qps。示例：使用50个并发连接，发出100000个请求，每个请求的数据为2kb，测试host为127.0.0.1端口为6379的redis服务器性能：./redis-benchmark -h127.0.0.1 -p 6379 -c 50 -n 100000 -d 2...=

所需jar：jedis-2.1.0.jar和commons-pool-1.5.4.jarJedis操作步骤如下：1->获取Jedis实例需要从JedisPool中获取；2->用完Jedis实例需要返还给JedisPool；3->如果Jedis在使用过程中出错，则也需要还给JedisPool；package com.ljq.utils;import redis

NoSQL最早起源1998年，2009年开发发展，主要用于超大规模数据的存储，这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。1）nosql主要遵循CAP定理：         在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer's theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:1. 一致

1、单一服务器：在一个服务器完全能够胜任工作时就没必要考虑分布式，这样部署简单，维护也方便很多；2、分片：1）特点数据的各个部分存放在集群的不同服务器中； 比如按字母来划分：以a-g开头的键值都存放到第一台服务器上，以h-n开头的存放到第二台...2）需要考虑的问题如何存放数据，让用户基本上只需从一台服务器上获取数据。 如果经常需要与多个结点

4.1.2　错误处理有些读者会有疑问，如果一个事务中的某个命令执行出错，Redis 会怎样处理呢？要回答这个问题，首先需要知道什么原因会导致命令执行出错。（1）语法错误。语法错误指命令不存在或者命令参数的个数不对。比如：redis> MULTI  OK  redis> SET key value  QUEUED  redis> SET key  (error) ERR 

一、Redis的Replication：    这里首先需要说明的是，在Redis中配置Master-Slave模式真是太简单了。相信在阅读完这篇Blog之后你也可以轻松做到。这里我们还是先列出一些理论性的知识，后面给出实际操作的案例。    下面的列表清楚的解释了Redis Replication的特点和优势。    1). 同一个Master可以同步多个Slaves。  

# By default Redis does not run as a daemon. Use 'yes' if you need it.# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.#Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程