Redis

什么是接口? 接口可以理解为url就是接口. 那么在其他语言里面接口也可以是约束类 restful规范是什么? RESTful是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。 URL: 1.url体现版本 2.url体现是API 3.用HTTPS 4.条件 5.面向资源编程 6.根据method的不用进行不同的操作 7.响应时添加状态码 常见的状态码 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。 201 CREATED - [POST/PUT/ PATCH]：用户新建或修改数据成功。 202 Accepted - [* ]：表示一个请求已经进入后台排队（异步任务） 204 NO CONTENT - [DELETE]：用户删除数据成功。 400 INVALID REQUEST - [POST/PUT/ PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。 401 Unauthorized - [* ]：表示用户没有权限（令牌、用户名、密码错误）。 403 Forbidden - [* ] 表示用户得到授权（与401错误相对），但是访问是被禁止的。 404 NOT FOUND - [* ]：用户发出的请求针对的是不存在的记录

本文主要和大家分享 5种Redis数据结构详解，希望文中的案例和代码，能帮助到大家。 转载链接：https://www.php.cn/php-weizijiaocheng-388126.html 2.1.1 全局命令 1 查看所有键 key* 2 键总数 dbsize (dbsize命令在计算键总数的时候不会遍历所有键，而是直接获取Redis内置的键总数变量，时间复杂度为O（1），而keys命令会遍历所有键，时间复杂度为O（n）,当Redis保存了大量键时，线上环境禁止使用) 3 检查键是否存在 exists key 存在返回1，不存在返回0 4 删除键 del key 返回成功删除键的个数，不存在的返回0 5 键过期 expire key seconds ttl 命令会返回剩余过期时间 -1 键没设置过期时间 -2 键不存在 6 键的数据类型结构 type key 返回类型，不存在返回none 2.1.2 数据结构和内部编码 每种数据结构都有自己的底层的内部编码实现，而且是多种实现，这样Redis会在合适的场景选择合适的内部编码 每种数据结构都有两种以上的内部编码实现，例如list数据结构包含了linkedlist和ziplist两种内部编码，可以通过object encoding命令查询内部编码 Redis这样设计有两个好处： 　　第一：可以改进内部编码

一、前言 1、ELK简介 ELK是Elasticsearch+Logstash+Kibana的简称 ElasticSearch是一个基于Lucene的分布式全文搜索引擎，提供 RESTful API进行数据读写 Logstash是一个收集，处理和转发事件和日志消息的工具 Kibana是Elasticsearch的开源数据可视化插件，为查看存储在ElasticSearch提供了友好的Web界面，并提供了条形图，线条和散点图，饼图和地图等分析工具 总的来说，ElasticSearch负责存储数据，Logstash负责收集日志，并将日志格式化后写入ElasticSearch，Kibana提供可视化访问ElasticSearch数据的功能。 2、ELK工作流 应用将日志按照约定的Key写入Redis，Logstash从Redis中读取日志信息写入ElasticSearch集群。Kibana读取ElasticSearch中的日志，并在Web页面中以表格/图表的形式展示。 二、准备工作 1、服务器&软件环境说明 服务器 一共准备3台CentOS7 Server 服务器名 IP 说明 es1 192.168.1.31 部署ElasticSearch主节点 es2 192.168.1.32 部署ElasticSearch从节点 elk 192.168.1.21 部署Logstash +

持久化 1、RDB 概念 RDB持久化可以在指定的时间间隔内生成数据集的时间点内存快照 配置 1、save 60 10000 2、rdbcompression yes 3、dbfilename "dump_6379.rdb" 4、dir "/appdata/redis/savefile"（AOF同） 命令 save 通过主进程，造成阻塞，期间不能执行任何命令 bgsave fork()子进程后台进行 优点 1、恢复速度快，但载入过程中会令redis一直处于阻塞状态，直到载入完成； 2、可压缩保存； 3、可最大化Redis性能，父进程fork子进程完成保存操作。 缺点 1、数据非实时保存，易丢失部分数据； 2、数据集大时，fork()操作耗时且消耗cpu。 2、AOF 概念 AOF 持久化记录服务器执行的所有写操作命令（append-only file） 配置 1、appendfsync 1、always 2、everysec 3、no（由系统决定同步频率） 2、appendonly yes 3、appendfilename "appendonly.aof" 4、auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb AOF还原过程 创建一个不带网络连接的伪客户端，因为redis的命令只能在客户端上下文中执行；

电子从业者一定对“单片机大师”周立功和ZLG这个品牌不陌生，尤其是在嵌入式解决方案上或许颇有研究。据了解，7月1日起，微信可直接办理ETC，而该服务设备中也有着ZLG的身影。另外，从智能路灯到停车场智能门禁系统，可以说ZLG其实已***到生活的各个智能场景。 云平台究竟有多重要？举一个例子，汽车零部件生产过程中，有着“零库存”的潜规则，但实行起来却困难重重，这恰恰是云平台大展身手的好机会。一方面通过对人员操作的管理规范，让零件生产数据化、可视化，另一方面，整体数据的计算、分析、预测，让零件达到真正的“零库存”。但实际在部署云平台时却与想象是“一个天上，一个地下”…… 6月28日，ZLG（立功科技·致远电子）于中国国际软件博览会上正式发布ZWS云平台，并以ZLG从“芯”到“云”作为此次发布的战略方向。21ic中国电子网受邀参加此次发布并采访，致远电子常务副总李佰华、云平台研发经理叶玉琳、工业互联网产品经理王锋出席现场，解答记者问题。 视频：ZWS云平台介绍 上云的瓶颈在于过程繁琐 现今，IoT的“炙手可热”让市面上几乎所有厂商都指向云平台这片海，但实际上云平台其实也是一块“难啃的硬骨头”。时代步入智能时代后，几乎人人都悉知云平台的好处，但大多云平台实际并不太对口，这种情况下就需要有行业经验并熟悉云平台的专业技术人员进行开发调试，而这其中云平台在代码的通用性或实用性上也许并不强。所以

一.什么是redis? Redis 是一个基于内存的高性能key-value数据库。 nosql 单线程 单进程的 支持事务 二.redis 数据类型： string list hash set hset 三.redis的优缺点 优点： 1.速度快,数据存在内存中 2.有丰富的数据类型，应用场景广泛 可用于缓存 消息 缺点： 1.受物理内存的限制 四.redis 应用场景： 1.会话缓存 2.全页缓存 3.队列 提供list 和set 的操作 push pop操作 4.排行榜 计数器 五.为什么redis 把所有数据放到内存中？ （为了快的读写速度） redis 为了最快的读写速度都读到内存中，并通过异步的方式将数据写入磁盘。如果不放入内存中，磁盘的io读写速度会影响redis 性能。 六. redis分布式锁 1.先拿setnx 来争夺锁，抢到之后 再用expire 给锁加一个过期时间防止锁忘记释放 若expire 命令 执行时出错，这个锁就会变成死锁，不被释放 解决方法 ： set 命令有复杂的参数 可以把setnx expire合成一条命令 redis.set(String key, String value, String nxxx, String expx, int time) ，这个set()方法一共有五个形参： 第一个为key，我们使用key来当锁，因为key是唯一的

接口的幂等性实际上就是 接口可重复调用 ， 在调用方多次调用的情况下，接口最终得到的结果是一致的 。有些接口可以天然的实现幂等性，比如查询接口，对于查询来说，查询一次和两次，对于系统来说，没有任何影响，查出的结果也是一样。 除了查询功能具有天然的幂等性之外，增加、更新、删除都要保证幂等性。那么如何来保证幂等性呢？ 全局唯一ID 如果使用全局唯一ID，就是根据业务的操作和内容生成一个全局ID，在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如数据库、redis等。如果存在则表示该方法已经执行。 从工程的角度来说，使用全局ID做幂等可以作为一个业务的基础的微服务存在，在很多的微服务中都会用到这样的服务，在每个微服务中都完成这样的功能，会存在工作量重复。另外打造一个高可靠的幂等服务还需要考虑很多问题，比如一台机器虽然把全局ID先写入了存储，但是在写入之后挂了，这就需要引入全局ID的超时机制。 使用主键冲突的策略进行防重，在并发量非常高的情况下对数据库性能会有影响 ，尤其是应用数据表和主键冲突表在一个库的时候，表现更加明显。其实针对是否会对数据库性能产生影响这个话题，我也和一些专业的DBA同学讨论过，普遍认可的是在 MySQL 数据库中采用主键冲突防重，在大并发情况下有可能会造成锁表现象，比较好的办法是

点击上方 “ 方志朋 ”， 选择“置顶或者星标” 你的关注意义重大！ 来源：my.oschina.net/u/3772106/blog/1793561 前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分离，集群 DBA 表优化，索引优化，等 分布式 nosql 主从分离，集群 主从分离，集群 主从分离，集群 redis mongodb memcache cdn html css js image 并发测试

一 、业务场景 在做项目系统接口服务的时候，为了防止客户端对于接口的滥用、保护服务器的资源， 通常来说我们会对于服务器上的各种接口进行请求次数的限制。比如对于某个用户，他在一个时间段内，比如 1 0秒，请求服务器接口的次数不能够大于一个上限，比如说 5 次。如果用户调用接口的次数超过上限的话，就直接拒绝用户的请求，返回错误信息。 服务接口的流量控制策略：限流、分流、降级、熔断等。本文讨论下限流策略，虽然降低了服务接口的访问频率和并发量，却换取服务接口和业务应用系统的高可用。 二、常用的限流算法 1、漏桶算法 漏桶(Leaky Bucket)算法思路比较简单 , 水 ( 请求 ) 先进入到漏桶里 , 漏桶以一定的速度出水 ( 接口有响应速率 ), 当水流进速度过大会直接导致桶溢出 ( 访问频率超过接口响应速率 ), 然后就拒绝请求 , 这里我们可以得出结论：漏桶算法能强行限制数据的传输速率。 漏桶算法的话一般有两个变量,一个是桶的大小 , 也就是你的承载量，比如流量突发增多时可以存多少的水 , 另一个就是你能够去正常处理的请求，水桶漏洞的大小。 因为漏桶的漏出速率是固定的,所以即使网络中不存在资源冲突 ( 没有发生拥塞 ), 漏桶算法也不能使流量突发到端口。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。 2、令牌桶算法 令牌桶算法(Token Bucket)和 Leaky

一般为了方便管理 redis 缓存，我们通过 : 来分隔不同的 key 来进行存储缓存，这样方便查看。 例如： game:upload_role:1000 game:member_info:2000 game:member_info:state_info:3000 上面的这种结构在 Redis Desktop Manager 中就会显示如下： 我们可以通过 keys 命令来获取 redis 里的所有 key。但这些 key 是没有层次的，如何生成？ 只能通过 : 分隔符来处理各 key 的上下层关系。 代码如下： function relationCache($keys, &$index, &$index_tree) { $result = []; if ($keys) { foreach ($keys as $key) { $arr = explode(':', $key); $len = count($arr); for ($ix = 0; $ix < $len; $ix++) { $cur_key = implode(':', array_slice($arr, 0, $ix + 1)); if (!isset($index_tree[$cur_key])) { $index_tree[$cur_key] = $index++; $pid = 0; if ($ix >= 1)