游戏服务器一个大区的游戏进程可以很多，比如多个负载均衡的登录进程，各区服游戏逻辑进程，有些游戏逻辑进程前面还往往还有个网关进程管理与客户端的链接，游戏逻辑进程有时为了利用多核性能会拆分不同进程，比如按场景划分进程，各区服之间通常还有跨服玩法使用的单独进程，当然mysql，etcd，redis等数据存储和cache进程也时常离不开。这么多进程互相之间需要提供服务和请求服务，如果都是各自维护一份配置文件，线上部署难度大且容易出错，通常运维会适配的开发一套运维工具，提供自动化部署，性能数据收集，进程监控，日志文件管理，事故告警等，同时开发也需要开发一些微服务中间件，例如服务发现，负载均衡等，以让集群中的微服务进程运转。

工作中遇到一个golang项目内存占用非常多，于是根据pprof工具反馈的热点做了优化，优化后通过pprof能看出来改善明显，原来的热点几乎不见了，但是top上显示的RSS内存占用却没什么变化，于是用runtime.ReadMemStats想看下runtime自己统计的内存占用相关信息，这个函数返回的结构体MemStats： ```Golang

今天在对一个golang工程做性能分析时遇到一个需求：有一个函数列表，存放了各种函数，程序一个一个处理列表中的函数，现在需要统计每个函数执行时间，并且打印执行慢的函数的名字及所在文件名和行号。runtime.FuncForPC可以获取一个函数的这些信息，但是参数需要传入函数地址，如何正确获取函数地址呢？取决于一个函数变量和函数地址的关系，让我们看一个例子： ```Golang package main

一般导入数据是按照行导入，但是有时只想导入一行中特定字段，一种可行的方案如下：

由于游戏业务逻辑的特殊性，并不适合转化成简单的数据库的CRUD操作，以及游戏对于时延的敏感、频繁操作数据对性能的高要求等，服务器的逻辑一般并不直接操作数据库，大多都是预先加载在内存进行操作，内存数据则定时异步存盘，数据库在这里主要提供了持久化功能，鲜少用到数据库的事务。这样的数据管理策略，在进程宕机时只会丢几分钟数据，且大部分需要数据一致性的数据大多时候刚好能在同一个批次存盘或者不存盘，线上实践中一般不会出问题或者出的问题可以忍受。然而，到了跨服交易行这种跨多个进程的需求，保持事务是不可绕过的需要解决的问题。