lua

开发访问量比较大的系统是，爬虫的目的就是解决访问量大的问题；缓存穿透是为了保护后端数据库查询服务；计数服务解决了接近真实访问量以及数据库服务的压力。 架构图 限流 就拿十万博客来说，如果存在热点文章，可能会有数十万级别的并发用户参与阅读。如果想让这些用户正常访问，无非就是加机器横向扩展各种服务，但凡事都有一个利益平衡点，有时候只需要少量的机器保证大部分用户在大部分时间可以正常访问即可。 亦或是，如果存在大量爬虫或者恶意攻击，我们必须采取一定的措施来保证服务的正常运行。这时候我们就要考虑限流来保证服务的可用性，以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务。 限流算法 任何限流都不是漫无目的的，也不是一个开关就可以解决的问题，常用的限流算法有：令牌桶，漏桶。 令牌桶 令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送(百科)。 用户的请求速率是不固定的，这里我们假定为10r/s，令牌按照5个每秒的速率放入令牌桶，桶中最多存放20个令牌。仔细想想，是不是总有那么一部分请求被丢弃。 漏桶 漏桶算法的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制

Redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。 Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。 使用规范 冷热数据区分 虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。 业务数据分离 不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 消息大小限制 由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。 连接数限制 连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机宕机。请确保使用了正确的 Redis 客户端连接池配置。 缓存 Key 设置失效时间

点击上方蓝色“ 方志朋 ”，选择“设为星标” 回复“ 666 ”获取独家整理的学习资料！ 来源：小姐姐味道 redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。 Redis 根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。redis 的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。 使用规范 冷热数据区分 虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。 业务数据分离 不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 消息大小限制 由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。 连接数限制 连接的频繁创建和销毁，会浪费大量的系统资源

使用nginx 反向代理 正向代理 负载均衡 nginx使用lua脚本 来源： oschina 链接： https://my.oschina.net/u/4285706/blog/4706387

前言 秋高气爽的一天，那时候年轻帅气的我正在参照着搜索引擎写代码，迷之微笑般的敲着键盘(又从搜索引擎上找到代码案例啦)，突然领导在小隔间里传来了呼唤声，然后有了以下场景： 领导：小Z，你过来一下； 当时小年轻的我，拿上纸和笔以迅雷不及掩耳之势般的速度来到领导跟前； 领导：有个需求，把现在xxx项目的Redis持久化给用上，最好今天下班前搞定，然后用上； 初碰Redis的我，当时很懵，只会简单的程序操作，只能小声的回复：好的，我回去查查； 真实案例，短短两句话就把需求沟通完了，肯定是有问题的，不是领导没说清楚，而是当时真是菜的不行，连问啥都不知道。好在最后在同事的帮助之下多次与领导沟通，最终完成任务。 对于真正做事，上面的工作需求沟通是有很大问题的：比如持久化频率？对持久化数据完整性的要求？这些都不确定，最终可能得到结果就不一样，最主要是这些功能直接通过Redis配置文件修改即可完成，当时听到需求的时候还以为要写程序，心里还想着这么短的时间咋能完成。所以学习很重要，类似于这种通过配置文件进行功能配置的应用实在太多，比如MySql，ngnix等等。 既然知道是这么回事，肯定要避免下次出现同样的尴尬，于是把Redis配置文件啃了一遍； 正文 redis的配置文件注释其实很详细，在配置文件中，用#开头的形式对每个配置项进行描述说明，如下图对端口的说明： 配置文件位置，这里仅参考

www.toutiao.com/a6752317753866060299 导读：在实际项目中Redis常被应用于做缓存，分布式锁、消息队列等。但是在搭建配置好Redis服务器后很多朋友应该会发现和有这样的疑问，为什么Redis默认建立了16个数据库，如下图所示。 一、16个数据库的由来 Redis是一个字典结构的存储服务器，一个Redis实例提供了多个用来存储数据的字典，客户端可以指定将数据存储在哪个字典中。这与在一个关系数据库实例中可以创建多个数据库类似（如下图所示），所以可以将其中的每个字典都理解成一个独立的数据库。 以MySQL实例为例 Redis默认支持16个数据库，可以通过调整Redis的配置文件redis/redis.conf中的databases来修改这一个值，设置完毕后重启Redis便完成配置。 客户端与Redis建立连接后会默认选择0号数据库，不过可以随时使用SELECT命令更换数据库。 在实际项目中则可以通过以Redis配置文件的形式指定数据库，如下图所示 二、正确理解Redis的“数据库”概念 由于Redis不支持自定义数据库的名字，所以每个数据库都以编号命名。开发者则需要自己记录存储的数据与数据库的对应关系。另外Redis也不支持为每个数据库设置不同的访问密码，所以一个客户端要么可以访问全部数据库，要么全部数据库都没有权限访问。但是，要正确地理解Redis的

目录 一、API 网关的用处 二、API网关在企业架构中的地位 三、企业中如何应用API网关 四、API网关有哪些竞争方案 五、API网关解决方案 六、企业怎么选择API网关 一、API网关的用处 API网关我的分析中会用到以下三种场景。 1、Open API 企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供。最好的例子就是淘宝开放平台、腾讯公司的QQ开发平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。 2、微服务网关 微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。 API 网关在微服务架构中正是以微服务网关的身份存在。 3、API服务管理平台 上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务改动太大，对企业来说成本太高。 但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题

什么是热更新，为什么需要热更新？ 热更新是目前各大手游等众多App常用的更新方式。简单来说就是在用户通过App Store下载App之后，打开App时遇到的即时更新。对于手游客户端来说，受到苹果审核的约束， 一次审核提交需要10~20天不等的等待时间。而这段时间开发进度依然会推进很多，一旦手游上线，第一个版本在玩家疯狂行为下，出点问题是必然的，所以”在线更新” 就成了家常便饭与必然。如果你要求必须整体重新下载完整下载包体，无法热更， 那么10~20多天后，游戏估计就没啥人了。 热更新要解决的问题？ 1: 更新频繁而IOS审核长，IOS无法用DLL反射机制去做代码更新。 如果无热更新机制，则客户端每次都需要玩家重新下载一次完整的安装包，用户体验不好。 2: 解决发布包的容量问题，一切都可以增量下载。 热更新的基本原理是什么？ 首先要清楚Unity的打包原理，也就是AssetBundle的打包机制，他会把prefab打包成.asset格式作为传输的数据。通过校验文件的MD5值来判断是否需要更新，如果需要更新则下载差异文件。lua属于解释性文件所以能通过www直接下载到本地，通过C#与lua交互，把逻辑写在lua里，从而实现代码热更新。 为什么需要带热更新的框架？ 在中大型商业项目中，基于以上热更新的实际运营需求，国内外各大游戏公司纷纷基于国内已知技术与成熟插件

　　 上一篇笔者介绍了关于什么是热更新，为什么需要热更新的技术文章。本篇就专门针对UI框架的热更新功能实现部分展开讨论，讨论的重点是热更新如何与UI框架进行结合？ 　　现在笔者把设计“UI热更新框架”的整体设计与构建过程表述如下，最后附带源码工程的下载链接，供广大学员参考研究。如果大家有什么不明白的地方，欢迎大家在评论区进行讨论。 1：首先基于笔者以前设计的SUIFW 框架，做进一步功能完善。 　 完善UI框架对于复杂窗体的直接转向功能。为了小伙伴们能够更好的理解本技术，文章末尾特提供了下载链接供大家参考。 2：经过重构完善后UI框架与AB框架(即：AssetBundle 框架，本框架文章末尾提供源码下载链接) 的初步资源、脚本整合处理。 　2.1> 建立一个全新的项目名称例如：UIPlusABFramework。 2.2> 项目中增加存放需要打包资源的目录。 例如“AB_Resurces”目录。 2.3> Resources目录原来的资源文件，除了配置文件外，全部拷贝到AB_Resources 目录下。使用AB框架，对资源进行打包处理，加载到StreamingAssets 目录下。 3：原始UI框架核心类（UIMangager.cs）的改动。 3.1> 把原UI核心类底层加载机制 Resources.Load() 的单机职能，改为以AB框架为核心的AB包的调用加载机制。 具体说明