Golang 入门系列(一)Go环境搭建

安装 Go

Go语言的优劣,这里就不介绍了,下面直接讲Go 的安装:

Go 的官方网站http://golang.org/(需要FQ软件)

国内下载地址http://www.golangtc.com/download

下载对应平台的安装包。注意区分32位还是64位操作系统。

安装包下载完成之后,安装过程很简单,傻瓜式下一步到底就好了。

 

Go 环境变量

安装go 的时候,安装程序会自动把相关目录写到系统环境。但是如果是zip 的安装,需要自己手动添加。

主要配置以下几个:

  • GOROOT:Go 安装后的根目录(例如:D:\Go),安装过程中会由安装程序自动写入系统环境变量中。
  • GOBIN:Go 的二进制文件存放目录(%GOROOT%\bin)
  • PATH:需要将 %GOBIN% 加在 PATH 变量的最后,方便在命令行下运行。

当环境变量都配置完成之后,Go 就已经安装完毕了。打开命令行,运行 go 命令,就可以看到如下的提示了。

Go 工作空间

GOPATH : Go 的工作空间,就是我们的开发和依赖包的目录(例如:我的是 D:\Go_Path\go) ,此目录需要手动配置到系统环境变量

GOPATH 工作空间是一个目录层次结构,其根目录包含三个子目录:

  • src:包含 Go 源文件,注意:你自己创建依赖的package,也要放到GOPATH 目录下,这样才能够被引用到。
  • pkg:包含包对象,编译好的库文件
  • bin:包含可执行命令

注意:

1. 需要将GOPATH 路径,手动写入到系统环境变量。

2. 不要把 GOPATH 设置成 Go 的安装路径

3. 你自己创建依赖的package,也要放到GOPATH 目录下,这样才能够被引用到。

 

配置好之后,通过 go env 命令来查看go环境是否配置正确:

 

Hello World

现在,一起来 Hello World 吧!

复制代码
package main
import (
    "fmt"
)

func main() {
    fmt.Println("Hello World!") 
}
复制代码

 

将上面的程序保存成 helloworld.go,然后在命令行中执行:

go run helloworld.go

 

其他

1. IDE 的下载安装这里就不说,大家直接去这个地址下载就行。

Goland下载链接:https://www.jetbrains.com/go/download/#section=windows

2. 我用的是Atom 编辑器。配置有点麻烦,不建议大家使用。

3. 后面直接讲Go语言的如何使用。

4. 能翻的最好FQ,因为很多package 在golang官网,不FQ下载不下来。

 

干货| 架构师入门实战视频课程(二) 第二弹

《架构师入门实战视频课程》

前面第一篇的已经发布了一些,不了解的可以查看之前的文章,下载相关的资源

今天更新第二波,

废话不多说,直接上干货吧

注微信公众号,回复相关代码,即可获得相关资料,

例如:

1. 回复:svn,获取Svn版本管理与代码上线架构方案等 相关教程

2. 回复:git,获取 Git分布式版本控制系统权威指南 相关教程

3. 回复:java,获取 实战Java高并发程序设计模式视频 相关教程

4. 回复:solr,获取 实战搜索引擎Solr集群和应用 相关教程

5. 回复:zeromq,获取 基于案例学Java服务器端程序设计ZeroMQ Netty视频教程 相关教程

领取方式

关注微信公众号,回复相关代码,即可获取相关资料。

有任何问题可以联系我

长按自动识别二维码,关注本人微信公众号。

本期干货! 共享经济时代,默契操作! 声明:本次分享为自愿获取。

干货 | 架构师入门实战视频课程(一)

干货 | 架构师入门实战视频课程(一)

2018-04-04 码农章为忠

《架构师入门实战视频课程》

废话不多说,直接上干货吧

这次先整理了比较初级的视频教程,后续视频会慢慢整理出来。

关注微信公众号,回复相关代码,即可获得相关资料,

例如:

1. 回复:redis,获取 redis 相关教程

2. 回复:mongodb,获取 Mongodb 入门教程

3. 回复:mysql,获取 mysql 相关教程

4. 回复:zookeeper ,获取 Zookeeper 相关教程

5. 回复:nginx,获取 Nginx 相关教程

领取方式

关注微信公众号,回复相关代码,即可获取相关资料。

有任何问题可以联系我

长按自动识别二维码,关注本人微信公众号。

本期干货! 共享经济时代,默契操作! 声明:本次分享为自愿获取。

C#总结(六)EventBus事件总线的使用-自己实现事件总线

在C#中,我们可以在一个类中定义自己的事件,而其他的类可以订阅该事件,当某些事情发生时,可以通知到该类。这对于桌面应用或者独立的windows服务来说是非常有用的。但对于一个web应用来说是有点问题的,因为对象都是在web请求中创建的,而且这些对象生命周期都很短,因而注册某些类的事件是很困难的。此外,注册其他类的事件会使得类紧耦合。事件总线便可以用来解耦并重复利用应用中的逻辑。

 

事件总线带来的好处和引入的问题

好处比较明显,就是独立出一个发布订阅模块,调用者可以通过使用这个模块,屏蔽一些线程切换问题,简单地实现发布订阅功能。

坏处可能比较隐晦,但这些需要足够引起我们的重视

  • 大量的滥用,将导致逻辑的分散,出现问题后很难定位。
  • 没办法实现强类型,在编译的时候就发现问题。
  • 代码可读性有些问题,IDE无法识别这些协议,对IDE不友好。
总得来说,如果项目里面有大量的事件交互,那么还是可以通过EventBus来实现,否则还是推荐自己在模块内部实现观察者模式。

示例代码

所以今天介绍一个简单的事件总线,它是事件发布订阅模式的实现,让我们能在领域驱动设计(DDD)中以事件的弱引用本质对我们的模块和领域边界很好的解耦设计。

目前,所有的源代码已经提交到github 上,地址:https://github.com/weizhong1988/Weiz.EventBus

程序目录结构如下:

事件总线

事件总线是被所有触发并处理事件的其他类共享的单例对象。要使用事件总线,首先应该获得它的一个引用。下面有两种方法来处理:

订阅事件

触发事件之前,应该先要定义该事件。EventBus为我们提供了Subscribe 方法来订阅事件:

复制代码
        public void Subscribe<TEvent>(IEventHandler<TEvent> eventHandler) where TEvent : IEvent
        {
            //同步锁
            lock (_syncObject)
            {
                //获取领域模型的类型
                var eventType = typeof(TEvent);
                //如果此领域类型在事件总线中已注册过
                if (_dicEventHandler.ContainsKey(eventType))
                {
                    var handlers = _dicEventHandler[eventType];
                    if (handlers != null)
                    {
                        handlers.Add(eventHandler);
                    }
                    else
                    {
                        handlers = new List<object>
                        {
                            eventHandler
                        };
                    }
                }
                else
                {
                    _dicEventHandler.Add(eventType, new List<object> { eventHandler });
                }
            }
        }
复制代码

 

所以的事件都集成自IEvent,该类包含了类处理事件需要的属性。

复制代码
 var sendEmailHandler = new UserAddedEventHandlerSendEmail();
 var sendMessageHandler = new UserAddedEventHandlerSendMessage();
 var sendRedbagsHandler = new UserAddedEventHandlerSendRedbags();
 Weiz.EventBus.Core.EventBus.Instance.Subscribe(sendEmailHandler);
 Weiz.EventBus.Core.EventBus.Instance.Subscribe(sendMessageHandler);
 //Weiz.EventBus.Core.EventBus.Instance.Subscribe<UserGeneratorEvent>(sendRedbagsHandler);
 Weiz.EventBus.Core.EventBus.Instance.Subscribe<OrderGeneratorEvent>(sendRedbagsHandler);
复制代码

发布事件

对于事件源,则可以通过Publish 方法发布事件。触发一个事件很简单,如下所示:

复制代码
     public void Publish<TEvent>(TEvent tEvent, Action<TEvent, bool, Exception> callback) where TEvent : IEvent
        {
            var eventType = typeof(TEvent);
            if (_dicEventHandler.ContainsKey(eventType) && _dicEventHandler[eventType] != null &&
                _dicEventHandler[eventType].Count > 0)
            {
                var handlers = _dicEventHandler[eventType];
                try
                {
                    foreach (var handler in handlers)
                    {
                        var eventHandler = handler as IEventHandler<TEvent>;
                        eventHandler.Handle(tEvent);
                        callback(tEvent, true, null);
                    }
                }
                catch (Exception ex)
                {
                    callback(tEvent, false, ex);
                }
            }
            else
            {
                callback(tEvent, false, null);
            }
        }
复制代码

 

下面是发布事件的调用:

            var orderGeneratorEvent = new OrderGeneratorEvent { OrderId = Guid.NewGuid() };

            System.Console.WriteLine("{0}下单成功", orderGeneratorEvent.OrderId);
          
            Weiz.EventBus.Core.EventBus.Instance.Publish(orderGeneratorEvent, CallBack);

定义处理事件

要处理一个事件,应该要实现IEventHandler接口,如下所示:

复制代码
    /// <summary>
    /// send email
    /// </summary>
    public class UserAddedEventHandlerSendEmail : IEventHandler<UserGeneratorEvent>
    {

        public void Handle(UserGeneratorEvent tEvent)
        {
            System.Console.WriteLine(string.Format("{0}的邮件已发送", tEvent.UserId));
        }
    }
复制代码

处理多事件

在一个单一的处理句柄中,可以处理多个事件。这时,你应该为每个事件实现IEventHandler。比如:

复制代码
    /// <summary>
    /// red bags.
    /// </summary>
    public class UserAddedEventHandlerSendRedbags : IEventHandler<UserGeneratorEvent>,IEventHandler<OrderGeneratorEvent>
    {
        public void Handle(OrderGeneratorEvent tEvent)
        {
            System.Console.WriteLine(string.Format("{0}的下单红包已发送", tEvent.OrderId));
        }

        public void Handle(UserGeneratorEvent tEvent)
        {
            System.Console.WriteLine(string.Format("{0}的注册红包已发送", tEvent.UserId));
        }
    }
复制代码

 

最后

以上,就把事件总线介绍完了,完整的代码,请到github 上下载,这个只是EventBus 的简单实现,各位可以根据自己的实际场景和需求,优化修改。

Redis总结(七)Redis运维常用命令

redis 服务器端命令

redis 127.0.0.1:6380> time  ,显示服务器时间 , 时间戳(秒), 微秒数

1) “1375270361”

2) “504511”

 

redis 127.0.0.1:6380> dbsize  // 当前数据库的key的数量

(integer) 2

redis 127.0.0.1:6380> select 2

OK

redis 127.0.0.1:6380[2]> dbsize

(integer) 0

redis 127.0.0.1:6380[2]>

 

 

BGREWRITEAOF 后台进程重写AOF

BGSAVE       后台保存rdb快照

SAVE         保存rdb快照

LASTSAVE     上次保存时间

 

Slaveof master-Host port  , 把当前实例设为master的slave

 

Flushall  清空所有库所有键

Flushdb  清空当前库所有键

Showdown [save/nosave]

 

注: 如果不小心运行了flushall, 立即 shutdown nosave ,关闭服务器

然后 手工编辑aof文件, 去掉文件中的 “flushall ”相关行, 然后开启服务器,就可以导入回原来数据.

 

如果,flushall之后,系统恰好bgrewriteaof了,那么aof就清空了,数据丢失.

 

Slowlog 显示慢查询

注:多慢才叫慢?

答: 由slowlog-log-slower-than 10000 ,来指定,(单位是微秒)

 

服务器储存多少条慢查询的记录?

答: 由 slowlog-max-len 128 ,来做限制

 

Info [Replication/CPU/Memory..]

查看redis服务器的信息

 

Config get 配置项

Config set 配置项 值 (特殊的选项,不允许用此命令设置,如slave-of, 需要用单独的slaveof命令来设置)

 

Redis运维时需要注意的参数

1: 内存

# Memory

used_memory:859192 数据结构的空间

used_memory_rss:7634944 实占空间

mem_fragmentation_ratio:8.89 前2者的比例,1.N为佳,如果此值过大,说明redis的内存的碎片化严重,可以导出再导入一次.

2: 主从复制

# Replication

role:slave

master_host:192.168.1.128

master_port:6379

master_link_status:up

 

3:持久化

# Persistence

rdb_changes_since_last_save:0

rdb_last_save_time:1375224063

 

4: fork耗时

#Status

latest_fork_usec:936  上次导出rdb快照,持久化花费微秒

注意: 如果某实例有10G内容,导出需要2分钟,

每分钟写入10000次,导致不断的rdb导出,磁盘始处于高IO状态.

 

 

5: 慢日志

config get/set slowlog-log-slower-than

CONFIG get/SET slowlog-max-len

slowlog get N 获取慢日志

 

运行时更改master-slave

修改一台slave(设为A)为new master

1) 命令该服务不做其他redis服务的slave

命令: slaveof no one

2) 修改其readonly为yes

 

其他的slave再指向new master A

1) 命令该服务为new master A的slave

命令格式 slaveof IP port

C#总结(五)调用C++动态库(类型对照)

函数调用导致堆栈不对称。原因可能是托管的 PInvoke 签名与非托管的目标签名不匹配。
在dllimport中加入CallingConvention参数就行了,

[DllImport(PCAP_DLL, CharSet = CharSet.Auto, CallingConvention = CallingConvention.Cdecl)]


要注意C++与NET中数据类型的对应:

//c++:char * —- c#:string //传入参数
//c++:char * —- c#:StringBuilder//传出参数
//c++:char *变量名 —- c#:ref string 变量名
//c++:char *输入变量名 —- c#:string 输入变量名
//c++:char *输出变量名 —- c#:[MarshalAs(UnmanagedType.LPStr)] StringBuilder 输出变量名
//c++:SHORT(short) —- c#:System.Int16
//c++:LONG(long) —- c#:System.Int32

转载收集:

//C#调用C++的DLL搜集整理的所有数据类型转换方式,可能会有重复或者多种方案,自己多测试
//c++:HANDLE(void *) —- c#:System.IntPtr
//c++:Byte(unsigned char) —- c#:System.Byte
//c++:SHORT(short) —- c#:System.Int16
//c++:WORD(unsigned short) —- c#:System.UInt16
//c++:INT(int) —- c#:System.Int16
//c++:INT(int) —- c#:System.Int32
//c++:UINT(unsigned int) —- c#:System.UInt16
//c++:UINT(unsigned int) —- c#:System.UInt32
//c++:LONG(long) —- c#:System.Int32
//c++:ULONG(unsigned long) —- c#:System.UInt32
//c++:DWORD(unsigned long) —- c#:System.UInt32
//c++:DECIMAL —- c#:System.Decimal
//c++:BOOL(long) —- c#:System.Boolean
//c++:CHAR(char) —- c#:System.Char
//c++:LPSTR(char *) —- c#:System.String
//c++:LPWSTR(wchar_t *) —- c#:System.String
//c++:LPCSTR(const char *) —- c#:System.String
//c++:LPCWSTR(const wchar_t *) —- c#:System.String
//c++:PCAHR(char *) —- c#:System.String
//c++:BSTR —- c#:System.String
//c++:FLOAT(float) —- c#:System.Single
//c++:DOUBLE(double) —- c#:System.Double
//c++:VARIANT —- c#:System.Object
//c++:PBYTE(byte *) —- c#:System.Byte[]

//c++:BSTR —- c#:StringBuilder
//c++:LPCTSTR —- c#:StringBuilder
//c++:LPCTSTR —- c#:string
//c++:LPTSTR —- c#:[MarshalAs(UnmanagedType.LPTStr)] string
//c++:LPTSTR 输出变量名 —- c#:StringBuilder 输出变量名
//c++:LPCWSTR —- c#:IntPtr
//c++:BOOL —- c#:bool
//c++:HMODULE —- c#:IntPtr
//c++:HINSTANCE —- c#:IntPtr
//c++:结构体 —- c#:public struct 结构体{};
//c++:结构体 **变量名 —- c#:out 变量名 //C#中提前申明一个结构体实例化后的变量名
//c++:结构体 &变量名 —- c#:ref 结构体 变量名

//c++:WORD —- c#:ushort
//c++:DWORD —- c#:uint
//c++:DWORD —- c#:int

//c++:UCHAR —- c#:int
//c++:UCHAR —- c#:byte
//c++:UCHAR* —- c#:string
//c++:UCHAR* —- c#:IntPtr

//c++:GUID —- c#:Guid
//c++:Handle —- c#:IntPtr
//c++:HWND —- c#:IntPtr
//c++:DWORD —- c#:int
//c++:COLORREF —- c#:uint

//c++:unsigned char —- c#:byte
//c++:unsigned char * —- c#:ref byte
//c++:unsigned char * —- c#:[MarshalAs(UnmanagedType.LPArray)] byte[]
//c++:unsigned char * —- c#:[MarshalAs(UnmanagedType.LPArray)] Intptr

//c++:unsigned char & —- c#:ref byte
//c++:unsigned char 变量名 —- c#:byte 变量名
//c++:unsigned short 变量名 —- c#:ushort 变量名
//c++:unsigned int 变量名 —- c#:uint 变量名
//c++:unsigned long 变量名 —- c#:ulong 变量名

//c++:char 变量名 —- c#:byte 变量名 //C++中一个字符用一个字节表示,C#中一个字符用两个字节表示
//c++:char 数组名[数组大小] —- c#:MarshalAs(UnmanagedType.ByValTStr, SizeConst = 数组大小)] public string 数组名; ushort

//c++:char * —- c#:string //传入参数
//c++:char * —- c#:StringBuilder//传出参数
//c++:char *变量名 —- c#:ref string 变量名
//c++:char *输入变量名 —- c#:string 输入变量名
//c++:char *输出变量名 —- c#:[MarshalAs(UnmanagedType.LPStr)] StringBuilder 输出变量名

//c++:char ** —- c#:string
//c++:char **变量名 —- c#:ref string 变量名
//c++:const char * —- c#:string
//c++:char[] —- c#:string
//c++:char 变量名[数组大小] —- c#:[MarshalAs(UnmanagedType.ByValTStr,SizeConst=数组大小)] public string 变量名;

//c++:struct 结构体名 *变量名 —- c#:ref 结构体名 变量名
//c++:委托 变量名 —- c#:委托 变量名

//c++:int —- c#:int
//c++:int —- c#:ref int
//c++:int & —- c#:ref int
//c++:int * —- c#:ref int //C#中调用前需定义int 变量名 = 0;

//c++:*int —- c#:IntPtr
//c++:int32 PIPTR * —- c#:int32[]
//c++:float PIPTR * —- c#:float[]

//c++:double** 数组名 —- c#:ref double 数组名
//c++:double*[] 数组名 —- c#:ref double 数组名
//c++:long —- c#:int
//c++:ulong —- c#:int

//c++:UINT8 * —- c#:ref byte //C#中调用前需定义byte 变量名 = new byte();

//c++:handle —- c#:IntPtr
//c++:hwnd —- c#:IntPtr

//c++:void * —- c#:IntPtr
//c++:void * user_obj_param —- c#:IntPtr user_obj_param
//c++:void * 对象名称 —- c#:([MarshalAs(UnmanagedType.AsAny)]Object 对象名称

//c++:char, INT8, SBYTE, CHAR —- c#:System.SByte
//c++:short, short int, INT16, SHORT —- c#:System.Int16
//c++:int, long, long int, INT32, LONG32, BOOL , INT —- c#:System.Int32
//c++:__int64, INT64, LONGLONG —- c#:System.Int64
//c++:unsigned char, UINT8, UCHAR , BYTE —- c#:System.Byte
//c++:unsigned short, UINT16, USHORT, WORD, ATOM, WCHAR , __wchar_t —- c#:System.UInt16
//c++:unsigned, unsigned int, UINT32, ULONG32, DWORD32, ULONG, DWORD, UINT —- c#:System.UInt32
//c++:unsigned __int64, UINT64, DWORDLONG, ULONGLONG —- c#:System.UInt64
//c++:float, FLOAT —- c#:System.Single
//c++:double, long double, DOUBLE —- c#:System.Double

//Win32 Types —- CLR Type

//Struct需要在C#里重新定义一个Struct
//CallBack回调函数需要封装在一个委托里,delegate static extern int FunCallBack(string str);

//unsigned char** ppImage替换成IntPtr ppImage
//int& nWidth替换成ref int nWidth
//int*, int&, 则都可用 ref int 对应
//双针指类型参数,可以用 ref IntPtr
//函数指针使用c++: typedef double (*fun_type1)(double); 对应 c#:public delegate double fun_type1(double);
//char* 的操作c++: char*; 对应 c#:StringBuilder;
//c#中使用指针:在需要使用指针的地方 加 unsafe

//unsigned char对应public byte
/*
* typedef void (*CALLBACKFUN1W)(wchar_t*, void* pArg);
* typedef void (*CALLBACKFUN1A)(char*, void* pArg);
* bool BIOPRINT_SENSOR_API dllFun1(CALLBACKFUN1 pCallbackFun1, void* pArg);
* 调用方式为
* [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
* public delegate void CallbackFunc1([MarshalAs(UnmanagedType.LPWStr)] StringBuilder strName, IntPtr pArg);
*
*
*/

C#总结(四)调用C++动态库

由于公司很多底层的SDK,都是C++开发,上层的应用软件却是C# Winform程序。在实际工作的过程中,就经常碰到了C# 程序调用C++ 动态库的问题。最近一直在和C++ 打交道,C# 怎么调用C++ 类库函数。也遇到了一些问题,所以就来总结总结C#程序调用C++动态库时的各种坑。

 

1. 可能遇到的问题:

C#在调用动态库的过程中我也遇到了以下一些问题:

1、C++中有指针,C#中需要使用指针吗?

由于C++中的动态库中有指针参数,因此我也是用.NET的不安全代码,使用了C#的指针,但是也还是出现了一些问题,如在C#中传入的参数是一个二维数组时就出现了问题,最后只能改C++函数传入参数的参数类型。

2、C#和C++中的类型如何转换呢?

虽然C#和C++比较类似,但是其给我们的参数类型我们要与C#的参数类型一一对应起来,具体看后续说明。

3、C++函数中的CallingConventionCharSet 怎么设置?

调用C++函数之前一定要先确认,否则可能出现函数调用导致堆栈不对称。原因可能是托管的 PInvoke 签名与非托管的目标签名不匹配的问题。函数的CallingConvention和CharSet,可以查看动态库对应的 .h头文件。

4、如何反编译C++的dll的名称,端口?

可以通过Dependency Walker工具进行反编译查看别人写的动态库的信息

5、指针函数如何传参?

对于函数需要的指针函数,C# 调用时,可以定义委托来传入参数。

6、需要注意C++ dll 编译的平台是x86还是x64,是多字节的还是双字节的(Unicode)。

 

  2. 通过Dependency Walke查看dll的名称,端口

  下载Dependency 后将对应的C++ dll文件加载进去,就尅看到动态库的对应的信息,同时也可以通过.h 头文件查看。

 

 3. 如何调用

c#调用c++动态库一般我们这样写

    [DllImport(SDK, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
    public static extern int IKSDK_Release();
 1. DllImport的第一个参数SDK是动态库dll的路径,此dll放在程序运行的根目录或者c:windows/sytem32下,建议在程序根目录创建一个子目录来放置相应的C++ 动态库文件,方便以后更新。

2. CallingConvention 参数是c#调用c++的方式 是个枚举 msdn解释如下:

Cdecl 调用方清理堆栈。这使您能够调用具有 varargs 的函数(如 Printf),使之可用于接受可变数目的参数的方法。
FastCal 不支持此调用约定。
StdCall 被调用方清理堆栈。这是使用平台 invoke 调用非托管函数的默认约定。
ThisCall 第一个参数是 this 指针,它存储在寄存器 ECX 中。其他参数被推送到堆栈上。此调用约定用于对从非托管 DLL 导出的类调用方法。
Winapi 此成员实际上不是调用约定,而是使用了默认平台调用约定。例如,在 Windows 上默认为 StdCall,在 Windows CE.NET 上默认为 Cdecl

3. CharSet参数是控制名称重整以及将字符串参数封送到函数中的方式。 默认值为 CharSet.Ansi。

4. entrypoint参数用于标识函数在 DLL 中的位置。在托管对象中,目标函数的原名或序号入口点将标识跨越交互操作边界的函数。此外,您可以将入口点映射到一个不同的名称,这实际上是将函数重命名。一般默认不设置此参数。

5. 其他参数,请查看MSDN对于 DllImportAttribute 的说明。

 

4. 其他说明

C# 调用C++ 动态库,还有一个特别麻烦的问题就是参数对于的问题。后续会结合网上的资料总结一份详细的对照表。

 

如何内网搭建NuGet服务器

  NuGet 是.NET程序员熟知的工具,它可以直接安装开源社区中的各个公用组件,可以说是非常方便。不过,有些时候,公司内部的公用的基础类库,各个项目都有引用,但又不能发布到公共的NuGet服务器上,所以我们需要自己架设一个私有服务,通过NuGet 来的各个项目中用到的公共组件进行管理。就非常的方便。也便于组件版本的管理。

 

一、NuGet网站构建

  1. 创建一个空的ASNET网站

   

   注意:将Framework 设置为4.6 以上,NuGet.Server库 要求.net framework 的版本是4.6 。

 

  2. 用NuGet为 NuGetServer 安装“NuGet.Server”库。
 
  安装成功后,你的Solution会变成这样一个结构。并且不需要写任何代码或更改任何配置,它已经可以运行了。运行此网站,如果看到下面的欢迎界面,就表示网站已经构建完成了。
   
   注意:Packages里只有一个readme.txt,这个目录是用来放NuGet包的,点击 here 连接,可以查看现有的包。

  3. 部署网站

  这也和部署任何一个ASP.NET网站完全一样。这里不细说。
 

二、把代码打包为NuGet包

  1. 去Nuget官网下载nuget command line tool,

   下载地址:https://www.nuget.org/downloads

 

  2. 用Nuget打包

   Nuget 有两种打包方式:

   A:直接通过工程文件打包dll:

     1 创建一个类库,然后编译下。把刚才下载的nuget.exe拷贝到工程文件所在的文件夹中:

       

    2. 通过命令行来创建nuget包:nuget.exe pack

     

 

  B:使用nuget的spec文件进行打包,。

    1. 同样把要打包的DLL跟NuGet.exe放在一个目录下,用nuget spec命令创建一个nuspec文件:

    

 

    2. 打开Package.nuspec文件,可自定义一些配置,。

     注意$description$使用AssemblyDescriptionAttribute的值进行替换,在产生package之前,一定要记得先编译项目,否则会提示$description$找不到的错误;

 

    3. 用 NuGet pack打包成Nuget包:

     

 

 

  至此打包完毕。

 

三、 把NuGet包上传到服务器

  将打包好的.nupkg 文件 拷贝到 第一步中架好的Nuget服务器 的Package目录下。可以Nuget 服务中自己写一个文件上传的功能,来降低拷贝的麻烦。

四、配置Visual Studio

  Nuget 服务已经架设成功,接下来就要在VS里配置NuGet 源,让其他的项目可以使用我们的NuGet服务器。
  选择工具-》Nuget包管理器-》程序包管理控制台,点击 配置图标:

   

添加,设置本地的NuGet源名字和地址即可。注意:source 最后是 /nuget

  完成后,我们的VS就可以从私服上安装NuGet包了。

五、在其他项目中使用 

  到目前为止NuGet服务器端已经配置完成,类库和DLL文件的打包也介绍完毕, 接下来我们该如何在项目中引用内网NuGet 服务器中的包呢,步骤如下:

  1、 新建一个NuGetTest 项目,然后 工具-》Nuget包管理器-》程序包管理控制台 ,在命令行:install-package IKSDK 

 

  2、最后看看效果啦:

 

至此,内网搭建NuGet服务器 的过程就介绍完了,,

 

 

电商总结(八)如何打造一个小而精的电商网站架构

前面写过一些电商网站相关的文章,这几天有时间,就把之前写得网站架构相关的文章,总结整理一下。把以前的一些内容就连贯起来,这样也能系统的知道,一个最小的电商平台是怎么一步步搭建起来的。对以前的文章感兴趣的朋友可以看这个,http://www.cnblogs.com/zhangweizhong/category/879056.html

本文大纲:

1. 小型电商网站的架构

2. 日志与监控系统的解决方案

3. 构建数据库的主从架构

4. 基于共享存储的图片服务器架构

5. 移动M站建设

6. 系统容量预估

7. 缓存系统

 

一、小型电商网站的架构

 

刚从传统软件行业进入到电商企业时,觉得电商网站没有什么技术含量,也没有什么门槛,都是一些现有的东西堆积木似的堆出来罢了。然而,真正进入到这个行业之后,才发现并非如此。有人说过,好的架构,是演化出来的,电商网站的架构也是如此。现在好的电商网站,看似很复杂,很牛逼,其实也是从很小的架构,也是从没什么技术含量开始的。所以,架构的演化过程,就是在技术团队不断追求极致的过程。

 

今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构,往往会采用一个比较典型的LAMP架构,前端加上Apache/PHP,后端是MySQL。这个算是比较流行的。不过,目前还有一套.net的技术架构,可能大家很少提到。很不幸,我就是在一个.net平台为基础的电商公司。所以,今天也是要总结.net 平台的电商架构。

 

1技术架构

 

 

一般初期的电商网站,基本就几个业务子系统:网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以,MVC + 缓存 + 数据库基本就搞定了。

 

单就开发效率而言,.net MVC 的技术架构不会比LAMP开发速度慢。所以,一些企业,为了快速推出自己的电商平台,也会采用.net 架构。

 

2基础架构

 

 

上图为基础架构层面。这是一个很简单的基础架构。

 

  • 前端网站和M站,考虑到访问量和系统的可用性,基本会采用分布式部署。通过代理服务器进行请求分发。
  • 其它的业务子系统,像商家前台和管理系统,基本上都是单机或是主从部署。
  • 各个DB ,Redis 服务和文件和图片服务,搜索引擎Solr服务等,采用主从部署。

 

3详细架构

 

 

整个系统架构里面,还有一个比较重要的组成部分,那就是监控系统。例如:流量监控、硬件监控、系统性能监控等, 还有就是对某个页面进行监控,设置页面的其中一块进行监控等。它是提高整个平台可用性的一个重要手段。多平台、多个维度的监控,能够确保系统的可用性。一旦出现异常,特别在硬件或者性能方面出现异常,监控系统也能立刻发出警告,这样也好防范于未然。

 

总而言之,一个好的系统架构应该从扩展性、安全性、性能和可靠性来考虑。罗马不是一天建成的,架构适合就行,可以先行之而后优。通过渐进演化的过程,逐步让系统越来越完善。

 

 

二、日志与监控系统的解决方案

 

监控系统主要用于服务器集群的资源和性能监控,以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性不必多说。总之,只有实时了解各系统的状态,才能保证各系统的稳定。

 

 

如上图所示,监控平台监控的范围很广,从服务器性能及资源,到应用系统的监控。每个公司都有特定的平台统一监控的需求及解决方案,但监控平台的任务和作用基本是一致的。

 

1日志

 

日志是监视程序运行的一种重要的方式,主要有两个目的:1.bug的及时发现和定位;2.显示程序运行状态。

 

正确详细的日志记录能够快速的定位问题。同样,通过查看日志,可以看出程序正在做什么,是不是按预期的设计在执行,所以记录下程序的运行状态是必要的。这里将日志分为两种:1.异常日志;2.运行日志。

 

我们主要是使用log4net,将各个系统的日志,持久化记录到数据库或者文件中,以方便后续的系统异常监控和性能分析。如何集成log4net,这里不多说。

 

日志记录的几个原则:

  • 日志级别一定要区分清楚,哪些属于error、warning、info等。
  • 记录错误的位置。如果是分层系统,一定要在某个层统一处理,例如我们的MVC架构,都是在各个Action中Catch异常并处理,而业务层和数据库层这些地方的异常,都是Catch到异常后,往上一层抛。
  • 日志信息清晰准确有意义,日志尽量详细点,以方便处理。应该记录相关系统、模块、时间、操作人、堆栈信息等。方便后续处理。

 

2监控

 

监控系统是一个复杂的系统平台,目前有很多的开源产品和平台。不过我们平台小,监控任务和需求少,所以基本都是自己开发。主要有这五个方面:1.系统资源;2.服务器;3.服务;4.应用异常;5.应用性能。

 

具体的架构图如下:

 

 

1)系统资源监控

监控各种网络参数和各服务器相关资源(CPU、内存、磁盘读写、网络、访问请求等),保证服务器系统的安全运营,并提供异常通知机制以让系统管理员快速定位/解决存在的各种问题。目前比较流行的应该是Zabbix。

 

2)服务器监控

服务器的监控,主要是监控各个服务器、网络节点、网关等网络设备的请求响应是否正常。通过定时服务,定时去Ping各个网络节点设备,以确认各网络设备是否正常。如果哪个网络设备出现异常,则发出消息提醒。

 

3)服务监控

服务监控,指的是各个Web服务、图片服务、搜索引擎服务、缓存服务等平台系统的各项服务是否正常运行。可以通过定时服务,每隔一段时间,就去请求相关的服务,以确保平台的各项服务正常运行。

 

4)应用异常监控

目前我们平台所有系统的异常记录,都记录在数据库中。通过定时服务,统计分析一段时间之内的异常记录。如果发现有相关重要的模块的系统异常,比如支付、下单模块频繁发生异常,则立即通知相关人员处理,确保服务正常运行。

 

5)应用性能监控

在API接口和各应用的相关位置进行拦截和记录下程序性能(SQL性能,或是 程序执行效率)。相关重要模块提供性能预警,提前发现问题。 同时统计相关监控信息并显示给开发的人员,以方便后续的性能分析。

 

 

三、构建数据库的主从架构

 

发展到大型成熟的公司之后,主从架构可能就有点落伍了,取而代之的是更加复杂的数据库集群。但作为一个小型电商公司,数据库的主从架构应该是最基础的。任何大型的系统架构,都是不断演进的。主从架构便是数据库架构中最基础的架构。所以研究完主从架构,也就能看懂更加复杂的架构了。

 

首先为什么要读写分离?

 

对于一个小型网站,可能单台数据库服务器就能满足需求。但在一些大型的网站或者应用中,单台的数据库服务器可能难以支撑大的访问压力,升级服务器性能成本又太高,所以必须要横向扩展。还有就是,单库的话,读、写都是操作一个数据库。数据多了之后,对数据库的读、写性能就会有很大影响。同时对于数据安全性和系统的稳定性也是挑战。

 

数据库的读写分离的好处?

 

  • 将读操作和写操作分离到不同的数据库上,避免主服务器出现性能瓶颈;
  • 主服务器进行写操作时,不影响查询应用服务器的查询性能,降低阻塞,提高并发;
  • 数据拥有多个容灾副本,提高数据安全性,同时当主服务器故障时,可立即切换到其他服务器,提高系统可用性。

 

 

读写分离的基本原理就是让主数据库处理事务性增、改、删操作(Insert、Update、Delete)操作,而从数据库处理Select查询操作。数据库复制被用来把事务性操作导致的变更同步到其它从数据库。

 

以SQL为例,主库负责写数据、读数据。读库仅负责读数据。每次有写库操作,同步更新到读库。写库就一个,读库可以有多个,采用日志同步的方式实现主库和多个读库的数据同步。

 

1SQL Server 读写分离的配置

 

SQL Server提供了三种技术,可以用于主从架构之间的数据同步的实现:日志传送、事务复制和SQL 2012 中新增的功能Always On 技术。各自优劣,具体的大家自己去百度吧,这里提供网上的朋友的配置方式,仅供参考。

 

 

(图源:网络)

 

2C# 数据库读写操作

 

C#的请求数据库操作,单数据库和主从架构的数据库还是不一样的。主从架构的数据库,为了保证数据一致性,一般主库可读可写,从库只负责读,不负责写入。所以,实际C#在请求数据库时,要进行区别对待。

 

最简单的就是:配置两个数据库连接,然后在各个数据库调用的位置,区分读写请求相应的数据库服务器,如下图:

 

第二种解决方案就是判断SQL语句是写语句(Insert 、Update、Create、 Alter)还是读语句(Select)。

 

Demo下载:http://files.cnblogs.com/files/zhangweizhong/Weiz.DB.rar

 

(PS:此Demo为本人总结,跟实际生产中的DLL 不太相同,但原理是一样的,大家总结封装吧)

 

 

同时,增加相关的数据库配置

 

 

 

四、基于共享存储的图片服务器架构

 

在当前这个互联网的时代,不管何种网站,对图片的需求量越来越大。尤其是电商网站,几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构、扩展、升级的过程中,肯定也会碰到各种各样的问题与需求。当然这并不代表,你就必须得弄一个特别NB的图片服务架构,只要简单、高效、稳定就行。这部分我们来总结一个特别简单、高效的图片服务架构:通过共享存储的方式来实现图片服务架构。

 

然而,也有一些人问我,现在大型网站的图片服务器的架构已经完全不是这样了,别人家的图片系统比你这个牛逼多了,为啥不直接写那个呢?

 

事实是:第一,大型牛逼的系统我也不会;第二, 再牛逼的系统也是从小的架构演化过去的,没有一步到位的。这里介绍图片服务器架构虽然比较简单,但也是经过了单机时代的演化了,基本上可以满足中小型分布式网站的需求。这种架构的搭建和学习成本都极低,符合目前“短平快”的开发模式。

 

通过共享目录的方式实现共享存储 ,在共享目录文件服务器上配置独立域名,这样可以将图片服务器和应用服务器进行分离,来实现独立图片服务器。

 

优点:

1. 将图片服务和应用服务分离,缓解应用服务器的I/O负载。

2. 通过共享目录的方式来进行读写操作,可以避免多服务器之间同步相关的问题。

3. 相对来讲很灵活,也支持扩容/扩展。支持配置成独立图片服务器和域名访问,方便日后的扩展和优化。

4. 相对于更加复杂的分布式的NFS系统,这种方式是性价比高,符合目前互联网的“短平快”的开发模式。

 

缺点 :

1. 共享目录配置有些繁琐。

2. 会造成一定的(读写和安全)性能损失。

3. 如果图片服务器出现问题,那所有的应用都会受到影响。同时也对存储服务器的性能要求特别高。

4. 图片上传操作,还是得经过Web服务器,这对Web服务器还是有巨大的压力。

 

架构非常简单,基本架构如下图所示:

 

 

 

在存储服务器上建立一个共享目录(具体方式,我就不去重复了,自己百度吧,注意共享目录的文件安全)。

 

各个应用直接通过共享目录(\\192.168.1.200),将图片上传到存储服务器上。

 

建立一个Web站点(i1.abc.com)将该共享目录通过Web站点发布出去。这样其它的应用就能访问到相关图片。

 

所以,各应用将文件上传到共享目录

 

//保存原图
//完整的地址:\\192.168.1.200\lib\2016\03\04\10\IMG\4ugvvt6m9gdu.jpg
relativePath = relativeDir + fileName + imageExtension;

var absolutePath = ConfigHelper.SharePath + relativePath;

fileData.SaveAs(absolutePath);

 

上传成功后,可直接通过web 的方式访问:

http://i1.abc.com/lib/2016/03/04/10/IMG/4ugvvt6m9gdu.jpg

 

 

五、移动M站建设

 

最近在一直在搞M站,也就是移动Web站点。由于是第一次,也遇到了很多问题,所以把最近了解到的东西总结一番。聊一聊什么是移动M站,以及它有什么作用和优势。

 

有人会问,M站和APP有什么不同?

 

  1. APP直接在用户的移动设备上,曝光率相对较高。 而M站需打开浏览器,输入地址才能访问,所以曝光率相对较低。
  2. M站的推广的渠道相比移动APP,渠道较多,方便追踪用户来源、流量入口等,方便以后的活动推广和数据分析。
  3. M站用户无需安装,输入URL即可访问,而APP需要下载安装。
  4. M站能够快速地通过数据分析,能快速得到用户的反馈,从而更容易根据统计数据分析和用户的需求来调整产品。
  5. APP对用户更具粘性及用户体验也更好。
  6. M站对于营销推广活动非常方便,转发分享方便快捷。
  7. M站更新迭代产品速度和响应产品调整非常快,随时发布,而APP需要审核时间。
  8. M站跨平台,无需开发安卓和iOS版,只需有浏览器即可。

 

所以, 我觉得,M站和客户端是相辅相成的。M站的及时性和快捷性,是APP无法比拟的。而APP的用户体验,则是M站无法做到的。目前来说两者是不可能被对方完全替代的,在互联网营销大行其道的今天,M站也越来越重要。营销活动大多以H5页面的形式展示和传播。通过M站的营销和推广,从而又促进APP的使用和推广。

 

目前,移动M站有倾向APP的趋势。M站会越来越像个APP,使得M站也越来越重要。而且,很多APP的展示效果,在原生代码无法实现的时候,嵌套移动H5页面也是一个很好的选择。

 

下面介绍几个移动M站建设的要点:

 

151Degree

 

51Degrees号称是目前最快、最准确的设备检测的解决方案。它是一个免费开源的.NET移动应用开发组件,可以用来检测移动设备和浏览器。甚至可以获取屏幕尺寸、输入法、加上制造商和型号信息等。从而可以选择性地被定向到为移动设备而设计的内容。由于拥有精确的移动设备的数据,所以几乎支持所有的智能手机,平板电脑等移动设备。

 

其实说白了,51Degree的作用就是识别客户端的设备。PC浏览器访问,就跳转到PC站,手机浏览器访问就跳转到M站。从而达到更好的用户体验。

 

如何将51Degree加入到现有网站?

 

2架构

 

移动Web和传统的Web其实并没有本质的区别。说白了还是一个Web站点,使用的技术都是Html+CSS+JS。不同的是,只不过目前在Html5的大趋势下,将Html5加入到了移动M站,使得M站更像个轻APP。

 

 

3Bootstrap

 

Bootstrap就不多说了,网上有很多Bootstrap的资料。它最大的优势应该就是非常流行,非常容易上手。如果缺少专业的设计或美工,那么Bootstrap是一个比较好的选择。他的用法极其简单,几乎没什么学习成本,绝对是快速开发的利器。

 

官网:http://getbootstrap.com/
Github:https://github.com/twbs/bootstrap/

 

4几点建议

 

  • 移动M站的URL要尽量和PC相同,这是可以避免同一URL在PC站可以显示,但是在手机上打开却是404;
  • M站写单独的TDK。

 

 

六、系统容量预估

 

电商公司的朋友,这样的场景是否似曾相识:

 

运营和产品神秘兮兮的跑过来问:我们晚上要做搞个促销,服务器能抗得住么?如果扛不住,需要加多少台机器?

 

于是,技术一脸懵逼。

 

其实这些都是系统容量预估的问题,容量预估是架构师必备的技能之一。所谓,容量预估其实说白了就是系统在Down掉之前,所能承受的最大流量。这个是技术人员对于系统性能了解的重要指标。常见的容量评估包括流量、并发量、带宽、CPU、内存 、磁盘等一系列内容。这部分来聊一聊容量预估的问题。

 

1几个重要参数

 

  • QPS:每秒钟处理的请求数。
  • 并发量: 系统同时处理的请求数。
  • 响应时间:  一般取平均响应时间。

 

很多人经常会把并发数和QPS给混淆了。其实只要理解了上面三个要素的意义之后,就能推算出它们之间的关系:QPS = 并发量 / 平均响应时间。

 

2容量评估的步骤与方法

 

1)预估总访问量

 

如何知道总访问量?对于一个运营活动的访问量评估,或者一个系统上线后PV的评估,有什么好方法?

 

最简单的办法就是:询问业务方,询问运营同学,询问产品同学,看产品和运营对此次活动的流量预估。

 

不过,业务方对于流量的预估,应该就PV和用户访问数这两个指标。技术人员需要根据这两个数据,计算其他相关指标,比如QPS等。

 

2)预估平均QPS

 

  • 总请求数=总PV*页面衍生连接数
  • 平均QPS = 总请求数/总时间

 

比如:活动落地页1小时内的总访问量是30w PV,该落地页的衍生连接数为30,那么落地页的平均QPS=(30w*30)/(60*60)=2500。

 

3)预估峰值QPS

 

系统容量规划时,不能只考虑平均QPS,还要考虑高峰的QPS,那么如何评估峰值QPS呢?

 

这个要根据实际的业务评估,通过以往的一些营销活动的PV等数据进行预估。一般情况下,峰值QPS大概是均值QPS的3-5倍,如果日均QPS为1000,于是评估出峰值QPS为5000。

 

不过,有一些业务会比较难评估业务访问量,例如“秒杀业务”,这类业务的容量评估暂时不在此讨论。

 

4)预估系统、单机极限QPS

 

如何预估一个业务,一个服务器单机的极限QPS呢?

 

这个性能指标是服务器最基本的指标之一,所以除了压力测试没有其他的办法。通过压力测试,算出服务器的单机极限QPS 。

 

在一个业务上线前,一般都需要进行压力测试(很多创业型公司,业务迭代很快的系统可能没有这一步,那就悲剧了),以APP推送某营销活动为例(预计日均QPS为1000,峰值QPS为5000),业务场景可能是这样的:

 

  • 通过APP推送一个活动消息;
  • 运营活动H5落地页是一个Web站点;
  • H5落地页由缓存Cache和数据库DB中的数据拼装而成。

 

通过压力测试发现,Web服务器单机只能抗住1200的QPS,Cache和数据库DB能抗住并发压力(一般来说,1%的流量到数据库,数据库120 QPS还是能轻松抗住的,Cache的话QPS能抗住,需要评估Cache的带宽,这里假设Cache不是瓶颈),这样,我们就得到了Web单机极限的QPS是1200。一般来说,生产系统不会跑满到极限的,这样容易影响服务器的寿命和性能,单机线上允许跑到QPS1200*0.8=960。

 

扩展说一句,通过压力测试,已经知道Web层是瓶颈,则可针对Web相关的方面做一些调整优化,以提高Web服务器的单机QPS 。

 

还有压力测试工作中,一般是以具体业务的角度进行压力测试,关心的是某个具体业务的并发量和QPS。

 

5)回答最开始那两个问题

需要的机器=峰值QPS/单机极限QPS

 

好了,上述已经得到了峰值QPS是5000,单机极限QPS是1000,线上部署了3台服务器:

  • 服务器能抗住么? -> 峰值5000,单机1000,线上3台,扛不住
  • 如果扛不住,需要加多少台机器? -> 需要额外2台,提前预留1台更好,给3台保险

 

3总结

 

需要注意的是,以上都是计算单个服务器或是单个集群的容量。实际生产环境是由Web、消息队列、缓存、数据库等等一系列组成的复杂集群。在分布式系统中,任何节点出现瓶颈,都有可能导致雪崩效应,最后导致整个集群垮掉 (“雪崩效应”指的是系统中一个小问题会逐渐扩大,最后造成整个集群宕机)。

 

所以,要了解规划整个平台的容量,就必须计算出每一个节点的容量。找出任何可能出现的瓶颈所在。

 

 

七、缓存系统

 

 

对于一个电商系统,缓存是重要组成部分,而提升系统性能的主要方式之一也是缓存。它可以挡掉大部分的数据库访问的冲击,如果没有它,系统很可能会因为数据库不可用导致整个系统崩溃。

 

但缓存带来了另外一些棘手的问题: 数据的一致性和实时性。例如,数据库中的数据状态已经改变,但在页面上看到的仍然是缓存的旧值,直到缓冲时间失效之后,才能重新更新缓存。这个问题怎么解决?

 

还有就是缓存数据如果没有失效的话,是会一直保持在内存中的,对服务器的内存也是负担,那么,什么数据可以放缓存,什么数据不可以,这是系统设计之初必须考虑的问题。

 

什么数据可以放缓存?

 

  • 不需要实时更新但是又极其消耗数据库的数据。比如网站首页的商品销售的排行榜,热搜商品等等,这些数据基本上都是一天统计一次,用户不会关注其是否是实时的。
  • 需要实时更新,但是数据更新的频率不高的数据。
  • 每次获取这些数据都经过复杂的处理逻辑,比如生成报表。

 

什么数据不应该使用缓存?

 

实际上,在电商系统中,大部分数据都是可以缓存的,不能使用缓存的数据很少。这类数据包括涉及到钱、密钥、业务关键性核心数据等。总之,如果你发现,系统里面的大部分数据都不能使用缓存,这说明架构本身出了问题。

 

如何解决一致性和实时性的问题?

 

保证一致性和实时性的办法就是:一旦数据库更新了,就必须把原来的缓存更新。

 

说一说我们的缓存方案:我们目前的缓存系统:Redis(主从)+ RabbitMQ + 缓存清理服务组成,具体如下图:

 

缓存清理作业订阅RabbitMQ消息队列,一有数据更新进入队列,就将数据重新更新到Redis缓存服务器。

 

当然,有些朋友的方案,是数据库更新完成之后,立马去更新相关缓存数据。这样就不需要MQ和缓存清理作业。不过,这同时也增加了系统的耦合性。具体得看自己的业务场景和平台大小。

 

以上均为个人经验分享,不足之处请大伙轻点拍砖,有更好的建议欢迎留言。

 

Redis总结(六)Redis配置文件全解

前面已经写了一些关于redis 的介绍,redis 的基本功能和用法,基本上都说了,有问题的可以去看看 http://www.cnblogs.com/zhangweizhong/category/771056.html。今天把redis 配置文件里面,用到的一些常用的配置项总结总结。

==基本配置

port 6379  # 监听端口号,默认为 6379,如果你设为 0 ,redis 将不在 socket 上监听任何客户端连接。

daemonize no #是否以后台进程启动

databases 16 #创建database的数量(默认选中的是database 0)

save 900 1 #刷新快照到硬盘中,必须满足两者要求才会触发,即900秒之后至少1个关键字发生变化。
save 300 10 #必须是300秒之后至少10个关键字发生变化。
save 60 10000 #必须是60秒之后至少10000个关键字发生变化。

stop-writes-on-bgsave-error yes #后台存储错误停止写。
rdbcompression yes #使用LZF压缩rdb文件。
rdbchecksum yes #存储和加载rdb文件时校验。
dbfilename dump.rdb #设置rdb文件名。
dir ./ #设置工作目录,rdb文件会写入该目录。

==主从配置
slaveof 设为某台机器的从服务器
masterauth 连接主服务器的密码
slave-serve-stale-data yes # 当主从断开或正在复制中,从服务器是否应答
slave-read-only yes #从服务器只读
repl-ping-slave-period 10 #从ping主的时间间隔,秒为单位
repl-timeout 60 #主从超时时间(超时认为断线了),要比period大
slave-priority 100 #如果master不能再正常工作,那么会在多个slave中,选择优先值最小的一个slave提升为master,优先值为0表示不能提升为master。

repl-disable-tcp-nodelay no #主端是否合并数据,大块发送给slave
slave-priority 100 从服务器的优先级,当主服挂了,会自动挑slave priority最小的为主服

===安全
requirepass foobared # 需要密码
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 #如果公共环境,可以重命名部分敏感命令 如config

 

===限制
maxclients 10000 #最大连接数
maxmemory #最大使用内存

maxmemory-policy volatile-lru #内存到极限后的处理
volatile-lru -> LRU算法删除过期key
allkeys-lru -> LRU算法删除key(不区分过不过期)
volatile-random -> 随机删除过期key
allkeys-random -> 随机删除key(不区分过不过期)
volatile-ttl -> 删除快过期的key
noeviction -> 不删除,返回错误信息

#解释 LRU ttl都是近似算法,可以选N个,再比较最适宜T踢出的数据
maxmemory-samples 3

====日志模式
appendonly no #是否仅要日志
appendfsync no # 系统缓冲,统一写,速度快
appendfsync always # 系统不缓冲,直接写,慢,丢失数据少
appendfsync everysec #折衷,每秒写1次

no-appendfsync-on-rewrite no #为yes,则其他线程的数据放内存里,合并写入(速度快,容易丢失的多)
auto-AOF-rewrite-percentage 100 当前aof文件是上次重写是大N%时重写
auto-AOF-rewrite-min-size 64mb aof重写至少要达到的大小

====慢查询
slowlog-log-slower-than 10000 #记录响应时间大于10000微秒的慢查询
slowlog-max-len 128 # 最多记录128条

====服务端命令
time 返回时间戳+微秒
dbsize 返回key的数量
bgrewriteaof 重写aof
bgsave 后台开启子进程dump数据
save 阻塞进程dump数据
lastsave

slaveof host port 做host port的从服务器(数据清空,复制新主内容)
slaveof no one 变成主服务器(原数据不丢失,一般用于主服失败后)

flushdb 清空当前数据库的所有数据
flushall 清空所有数据库的所有数据(误用了怎么办?)

shutdown [save/nosave] 关闭服务器,保存数据,修改AOF(如果设置)

slowlog get 获取慢查询日志
slowlog len 获取慢查询日志条数
slowlog reset 清空慢查询

info []

config get 选项(支持*通配)
config set 选项 值
config rewrite 把值写到配置文件
config restart 更新info命令的信息

debug object key #调试选项,看一个key的情况
debug segfault #模拟段错误,让服务器崩溃
object key (refcount|encoding|idletime)
monitor #打开控制台,观察命令(调试用)
client list #列出所有连接
client kill #杀死某个连接 CLIENT KILL 127.0.0.1:43501
client getname #获取连接的名称 默认nil
client setname “名称” #设置连接名称,便于调试

 

====连接命令===
auth 密码 #密码登陆(如果有密码)
ping #测试服务器是否可用
echo “some content” #测试服务器是否正常交互
select 0/1/2… #选择数据库
quit #退出连接