weibocom / wqs Goto Github PK

It had better provide a graceful way to startup or shutdown wqs, this ensures that no messages are lost.

WQS Env

version: dev_beta   
commit: a819409e2c92832bf81946e0800b001d03a6910d 

Expected behavior

On memcached protocol, an empty value with "END" sent to the client, when the 'key' is not found or expired.

get group1.test1
END

Actual behavior

get group1.test1
SERVER_ERROR engine error Timeout

Steps to reproduce the issue

1. make build-qservice
2. ./qservice -config ./config.properties
3. printf "get group1.test1\r\n" | nc localhost 11211

Additional information you deem important

Timeout error is a look of confusion for biz clients, because timeout may happened out of limit of no messages.

Memcached protocol is one of the most popular protocols on the internet, wqs will partially support the memcached text protocl, including "set", "get" command.
We can post a message over text memcached protocol:

set queuename 0 0 11\r\nhello world\r\n

also we can consume the message simply as following:

get queuename\r\n

At first glance, message should not IDable, just for in most cases, messages will be consumed sequentially in couple of seconds. There is no need to retrieve message randomly by ID, but ID is still useful in some common reasons:

1. locate the duplicated messages
2. issue track.
3. message may be reordered, ID will help us find out why.

把当前相互独立的mc servere、HTTP server改为
Server层（全部控制HTTP API、引入Web框架和权限管理），Server层下再延伸出各个协议的子server来提供各个协议的消息发送和接受。

HTTP API need change to Restful style?
If do this, maybe graceful.

'go test' is a very useful tool to help the developers find out and figure out unapparent vulnerabilities. The coverage is expectedly close to 100%, but at least 30% of first released version 0.1.0 is more practical. The coverage will increase stably in the future version.

Typically, performance is a measure of the speed and efficiency with witch a message service delivers messages from producer to consumer. How every, in WQS, there are different aspects of performance we care about.

Message throughput The number of messages or message bytes per second

Latency The time it takes a particular message to be delivered from producer to consumer.

Stability The overall availability of message service or how gracefully it degrades in cases of heavy load or failure.

Connection Load The number of message producers, or message consumers, or the number of concurrent connections a system can support.

In many high availability scenarios, whole datacenter crash is supposed to happen any time. So many applications are build cross multiple IDCs, every single data center services a portion of traffics and accommodates the whole complete data. Every IDC will sync the traffic to the other data centers.
As a queue service, WQS should provide a abstract layer, so that the application developer programming cross multi-IDCs is as easy as single IDC.

1. producing a message is as fast as locally
2. consuming a message is as fast as locally
3. consuming latency is in a tolerable level
4. the throughput is as high as locally
5. the data stability is the same as locally

There are three message delivery semantics.

• exactly once
• at most once
• at least once

What people really want is definitely "exactly once", where by duplicate messages are not delivered. But within the context of a distributed system, "You Cannot Have Exactly-Once Delivery". [There are two common reasons duplicate may occur)[https://cwiki.apache.org/confluence/display/KAFKA/Idempotent+Producer]: one is network error when sending messages, the other is consumption's process crashes.
At most once semantics is easy to implement, actually in this condition the cluster will hit ultra high throughput and low latency, but data loss is an unacceptable option in many biz environment.

So, at least once delivery semantics becomes realistically the only option. We try everything to ensure no data loss, at the cost of complicated design, even if duplication.

WQS Env

version:   0.1.0
commit:

One WQS instance crash in multi WQS IDC envirement will make a few data repeated to read .
And when the crash one reboot , also make some data which have be readed readful .
The number of repeated data positively correlated with the threads of reading clients

如题，生成消费，都要经常proxy进行转发吗？底层使用kafka，增加这一层proxy主要目的是啥呢？

_go-metrics_