lua

思考：如何提升游戏逻辑开发效率 提升游戏逻辑开发效率的关键在于：游戏新增或修改功能时， 需要尽可能减少程序需要重复开发的代码量 。 下面主要考虑以下三种减少编码工作量的方法： <1>.尽可能将功能开发过程中 核心逻辑 （如收发协议，本地存储，距离检测等）封装成接口，可保证核心功能模块不因为团队人员水平差异在某些基础功能上出现异常或Bug。 <2>. 逻辑重复 ，仅在内容上有所扩展的功能尽可能让策划可以使用配表/工具进行修改。 <3>. 逻辑不重复 ，但逻辑关系可高度抽象或排列组合的功能，尽可能确定一套可修改逻辑关系的规则，在不修改解析代码的情况下实现这些不重复逻辑。 背景：客户端与服务器的角色逻辑 系统较为丰富的MMORPG游戏中，服务器分模块存储角色相关信息，实现某个新系统最容易想到的方法是在客户端登陆时/进入某个系统时主动向服务器请求相关信息。 但上述方法在游戏逐步添加新功能、属性、货币等时， 无论功能逻辑是否发生较大改变，均需要开发人员在代码中新增请求协议并进行重新解析 、存储、运算、显示，使用这一方法开发大型游戏会造成游戏逻辑开发效率低下，因此仍需要继续改进。 <1>常见封装核心逻辑方法：封装属性同步 属性一般包括如人物血量，攻击力，任务进度，副本完成情况等单个玩家信息。 1.服务器/客户端分别封装统一接口读取，修改和同步属性 2.数据可以自定义不同的数据结构，压缩

Lua基本语法 表类型 函数 Redis执行脚本 KEYS与ARGV 沙盒与随机数 脚本相关命令 原子性和执行时间 Lua是一种高效的轻量级脚本语言，能够方便地嵌入到其他语言中使用。在Redis中，借助Lua脚本可以自定义扩展命令。 Lua基本语法 数据类型 空(nil)，没有赋值的变量或表的字段值都是nil 布尔(boolean) 数字(number)，整数或浮点数 字符串(string),字符串可以用单引号或双引号表示，可以包含转义字符如\n \r等 表(table),表类型是Lua语言中唯一的数据结构，既可以当数组又可以当字典，十分灵活 函数(function)，函数在Lua中是一等值(first-class-value)，可以存储在变量中、作为函数的参数或返回结果。 变量 Lua的变量分为全局变量和局部变量，全局变量无需声明就可以直接使用，默认值是nil。 全局变量： a=1 -- 为全局变量a赋值 print(b) -- 无需声明即可使用，默认值是nil 局部变量： local c -- 声明一个局部变量c，默认值是nil local d=1 -- 声明一个局部变量d并赋值为1 local e,f -- 可以同时声明多个局部变量 但在Redis中，为了防止脚本之间相互影响，只允许使用局部变量。 赋值 Lua支持多重赋值，如： local a,b=1,2 --a的值是1

来源网站： www.wangdatao.com 前言 分布式系统中经常会提到限速和降级的概念。所谓限流，可以认为是服务降级的一种，限流就是限制系统的输入和输出流量， 以达到保护系统的目的 系统上线之前，一般都会进行压测，压测之后吞吐量是可以被测算的，为了保证系统的稳定运行， 一旦达到了设定限制的阔值，就需要限制流量并采取一些措施以完成限制流目的。常见的限流方案为：延迟处理、拒绝处理和部分拒绝处理等。一般高并发系统常见的限流有：限制总并发数（比如：数据库连接池、线程池）、限制瞬时并发数、限制时间窗口内的平均速率；其他还有如限制远程接口调用速率、限制MQ的消费速率；另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。 1、常用算法 1.1、计数器算法 算法思想： 规定一个时间周期，统计在一个周期内总共请求的次数，如果时间超过一个周期，则次数计入到下一个周期内。比如：当接收到第一个请求时，记录第一次的时间 beginTime, 计数器Counter设置为1，当第二个请求来时，判断第二个请求的时间与beginTime的间隔有没有超过最初设计的时间周期，如果没有超过，判断Counter是否超过设置的最大速度数，都满足时Counter加1；如果超过设计的时间周期，beginTime时间改为第二次请求的时间，Counter重置为1。 //不严谨的算法代码 public class

高并发系统限流-漏桶算法和令牌桶算法 参考： http://www.cnblogs.com/LBSer/p/4083131.html https://blog.csdn.net/scorpio3k/article/details/53103239 https://www.cnblogs.com/clds/p/5850070.html http://jinnianshilongnian.iteye.com/blog/2305117 http://iamzhongyong.iteye.com/blog/1742829 一、问题描述 　　某天A君突然发现自己的接口请求量突然涨到之前的10倍，没多久该接口几乎不可使用，并引发连锁反应导致整个系统崩溃。如何应对这种情况呢？生活给了我们答案：比如老式电闸都安装了保险丝，一旦有人使用超大功率的设备，保险丝就会烧断以保护各个电器不被强电流给烧坏。同理我们的接口也需要安装上“保险丝”，以防止非预期的请求对系统压力过大而引起的系统瘫痪，当流量过大时，可以采取拒绝或者引流等机制。 二、常用的限流算法 常用的限流算法有两种：漏桶算法和令牌桶算法 。 漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。 图1 漏桶算法示意图 对于很多应用场景来说