传统来说 redis 能够做什么？

远程内存数据库 不仅性能强劲 而且还有复制特性以及为解决各种问题而生的独一无二的数据结构（致力于帮助用户解决问题，而不会像其他数据库那样，要求用户扭曲问题来适应数据库）。

同时 复制 持久化 客户端分片等特性 可以很快将redis 进行扩展成一个包含数百GB的数据、每秒处理上百万次请求的系统

服务器被关闭的时候 数据咋办？

redis 提供两种不同形式的持久化方案 一是时间点转储 二是只追加文件（append-only）

工具会极大形式地改变人们解决问题的方式

但是不能盲目地只是使用工具 还要弄清楚工具的工作原理 优劣 能否有改进的地方 这些都是很有必要的

redis VS memcached

使用redis 存储聚合数据有三个好处：

• 将彼此相关的聚合数据放在同一个结构当中，这样访问数据就会变得更为容易；
• 将聚合数据放到有序集合里，构建出一个实时排行榜
• 聚合数据可以是整数或者浮点数 而memcached 只能是整数型的

数据结构：

• 字符串

一个常见的用途就是 缓存用户信息。

将用户信息结构体使用json 序列化 字符串，然后将序列化后的字符串塞进redis缓存。同样，取用户信息会经过一次反序列化的过程。

redis 的字符串 是动态字符串，是可以修改的字符串，内部结构实现上类似java 的 arraylist，采用预分配冗余空间的方式来减少内存的频繁分配

过期和 set 命令扩展

可以对key 设置过期时间，到点自动删除。这个功能常用来控制缓存的实效时间。

计数功能： 如果value 是一个值， 还可以进行自增操作，自增是有范围的，它的范围是signed long 的最大最小值，超过了这个值 redis 会报错

字符串 是 由多个字节组成的，每个字节又是由8个bit组成，因此也可看成很多bit 的组合，这便是bitmap（位图）数据结构

• 列表

相当与 java 中的 linkedlist 注意它是链表而不是数组

意味着插入和删除非常快 索引定位很慢

redis 的列表 常用来做异步队列使用 将需要延后处理的任务结构体 序列化成字符串 塞进 redis 的列表，另一个线程从这个列表中轮询数据进行处理

右进左出 队列

右边进 右边出 栈

慢操作

index 相当于 java 链表的 get(int index) 方法 它需要对链表进行遍历 性能随着参数index 增大而变差

ltrim 和字面上的含义不太一样，定义了一个区间 在这个区间内的值要保留 区间之外的统统砍掉 可以使用ltrim 来实现一个定长的链表 这一点非常有用

index=-1 表示倒数第一个元素

redis 底层存储的还不是一个 简单的 linkedlist 而是一个快速链表 quicklist 的结构

首先在列表元素较少的情况下 使用一块连续的内存存储 这个结构是ziplist 也即是压缩列表 所有的元素紧挨着一起存储 分配的是一块连续的内存 当数据量比较多的时候 才会改成 quicklist 因为普通的链表需要的附加指针空间太大，会比较浪费空间 而且会加重内存的碎片化 比如这个列表存的只是int 类型的数据 结构上还需要两个额外的指针prev 和 next 所以redis 将链表和ziplist 结合起来 组成了quicklist 也就是将多个ziplist 使用双指针串起来使用，这样既满足了快速的插入删除性能 也不会出现太大的空间冗余

• 字典（散列）

相当于 java 中的 hashmap 是无序字典 内部实现也是一样 同样的数组+链表二维结构 第一维hash 的数组位置碰撞时 就会将碰撞的元素使用链表串接起来

不同的是 redis 中的字典 只能是字符串另外它们 rehash的方式 不一样 java的 hashmap 在字典很大的时候 rehash 是一个耗时的操作 需要一次性 rehash redis 为了提高性能 不能阻塞服务 采用了渐进式rehash 的策略

渐进式 rehash 会在rehash 的同时 保留新旧两个hash 结构 查询时会同时查询两个hash 结构 查询时会同时查询两个hash 结构 然后在后续的定时任务中 以及hash 操作指令中 循序渐进地将旧hash 的内容一点点迁移到新的hash 结构中 当搬迁完成了 就会用新的hash 结构取而代之

当hash 移除了最后一个元素 该数据结构自动被删除 内存被回收

• 集合 set

集合和列表都可以存储多个字符串 集合通过不同的散列表来保证自己存储的每个字符串都是各不相同的（散列表只有键 没有与键相关联的值）
集合是无序的 因此 基本的几个命令为 sadd srem smembers sismember

集合常见操作 还有 并集 交集 差集

• 有序集合 zset

有序集合和字典一样 都用于存储键值对 ；

有序集合的值被称为分值（score），分值必须为浮点数。

有序集合是redis中唯一一个既可以根据成员访问元素 又可以根据分值以及分值的排列顺序来访问元素的结构

有序集合命令 zadd zrem zrange(根据元素在有序排列中所处的位置，从有序集合里面获取多个元素)

zrangebyscore(获取有序集合在給定分值范围内的所有元素)

计数器 （数据搜集 指标量化）

计数器的更新

清理旧计数器

存储统计数据

查找ip所属城市以及国家（关系映射）

redis 的配置信息

在线配置

• 一个标志位 web服务器是否在进行维护
• 为每个独立部分都分别运行一个redis服务器，比如专门负责记录日志、统计数据、专门进行缓存、存储cookies等 一台机器上是可以运行多个redis服务器的 只要端口号各不相同 就可以了
• 自动连接redis管理

自动补全的实现

分布式锁

一般对数据加锁 首先acquire 然后 release 对于多个线程访问的共享内存数据结构来说，这种先获取锁，然后执行操作，最后释放锁的动作非常常见。redis 使用watch 命令来代替对数据进行加锁 （乐观锁）

本地是使用mac air 做的基础尝试

使用的 是 3.0.0 的版本

/usr/local/Cellar/hadoop/3.0.0/libexec/etc/hadoop 主要都在这个目录下

1.配置hadoop-env.sh java_home路径

2.core-site.xml

1
2
3
4
5
6

<configuration>
 <property>
 <name>fs.defaultFS</name>
 <value>hdfs://localhost:9000</value>
 </property>
</configuration>

3.hdfs-site.xml

1
2
3
4
5
6

<configuration>
 <property>
 <name>dfs.replication</name>
 <value>1</value>
 </property>
</configuration>

4.mapred-site.xml

1
2
3
4
5
6

<configuration>
 <property>
 <name>mapreduce.framework.name</name>
 <value>yarn</value>
 </property>
</configuration>

5.yarn-site.xml

1
2
3
4
5
6
7
8
9
10

<configuration> 
<property> 
<name>yarn.nodemanager.aux-services</name> 
<value>mapreduce_shuffle</value> 
</property> 
<property> 
<name>yarn.nodemanager.env-whitelist</name>
 <value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value> 
</property> 
</configuration>

6 格式化文件系统

bin/hdfs namenode -format

启动 namenode 和 datanode

sbin/start-dfs.sh

节点可在 9870端口查看

让 HDFS 可以被用来执行 MapReduce jobs：

bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/root

启动 resourcemanager 和 nodemanager

sbin/start-yarn.sh

端口 8088

• python在风控领域，本身业界能熟悉从底层编译原理又到金融模型算法，又到机器学习都精通的人员参数并不多，需要能迅速适应和连接各大数据和金融领域的语言。
• 目前没有公开的行业标准状态，需要建立最适合自己的管理方式
• 产品形态多变，需求多变，需要找到切合的开发语言
• 核心模块，需要加快速度的 使用C 或者 C++完成
• GIL。这个问题不该你去考虑，有这瞎想的时间，关键点已经用C++完成了。

过早优化是罪恶之源 Donald Knuth

前期开发需要把注意力放在功能实现以及代码的可读性和维护上

• 风控不出事，觉得浪费成本；出了事情，还知道重要性！核心是如何做好风控
• web安全相关 要重视安全问题

ssh

1
2
3

ssh-keygen -t rsa

ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.1.101

文件相关操作

系统相关

协程：又称微线程，在单线程上执行多个任务，用函数切换，开销极小。不通过操作系统调度，没有进程、线程的切换开销。genvent，monkey.patchall

多线程请求返回是无序的，那个线程有数据返回就处理那个线程，而协程返回的数据是有序的。

缺陷：单线程执行，处理密集CPU和本地磁盘IO的时候，性能较低。处理网络I/O性能还是比较高.

使用gevent 或者是python3.6 及以上的asyncio

问题： 什么场景下使用协程反而会更差的性能？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def consumer():
    r = ''
    while True:
        n = yield r
        if not n:
            return
        print('[CONSUMER] Consuming %s...' % n)
        r = '200 OK'

def produce(c):
    c.send(None)
    n = 0
    while n < 5:
        n = n + 1
        print('[PRODUCER] Producing %s...' % n)
        r = c.send(n)
        print('[PRODUCER] Consumer return: %s' % r)
    c.close()

c = consumer()
produce(c)

新的写法

1
2
3
4
5
6
7
8
9
10
11

import asyncio


async def hello():
    print("Hello world!")
    r = await asyncio.sleep(1)
    print("Hello again!")
    
    
loop=asyncio.get_event_loop()
loop.run_until_complete(hello())

协程不是趋势，它是一个在历史中被挖掘出来的、对现有问题的一个有用的补充。

适用的场景：

• 高性能计算，牺牲公平性换取吞吐；
• 面向 IO Bound 任务，减少 IO 等待上的闲置，这其实和高性能计算领域内的优势是一致的；
• Generator 式的流式计算；
• 消除 Callback Hell，使用同步模型降低开发成本的同时保留更灵活控制流的好处，比如同时发三个请求；这时节约地使用栈，可以充分地发挥 “轻量” 的优势；

但并不是万灵丹：

• 如果栈使用得不节制，消耗的内存量和系统线程无异，甚至内存管理还不如系统线程（系统线程可以动态地调整虚拟内存，用户线程的 Segmented Stack 方案存在严重的抖动问题，Continous Stack 方案管理不当也会抖动，为了避免抖动则成了空间换时间，而内核在这方面做了多少 heuristic 呢）；
• IO Bound 任务可以通过调线程池大小在一定程度上缓解，目标是把 CPU 跑满即可，这点线程池的表现可能不完美，但在业务逻辑这个领域是及格的；
• 此外，一般的 python/ruby 任务并不是严格的 IO Bound，比如 ORM 的对象创建、模版渲染、GC 甚至解释器本身，都是 CPU 大户；单个请求扣去 redis 请求和数据库请求的时间，其它时间是否仍不少呢？
• CPU 上长时间的计算，导致用户线程的调度变差，不能更快地响应，单个请求的平均时间反而可能更长（诚然并发可能更高）；然而这在 python 这类 GIL 语言来看并不算劣势，甚至比 GIL 的调度更好，至少 gevent 可以知道各 IO 任务的优先级，而 GIL 的调度是事实上的 FIFO；