Thinking

今天是五一劳动节，劳动最光荣，我劳动，我快乐，前提是要搞好身体，愿家人和自己都有一个健康的身心去迎接未来的挑战。

回想几年前生病的那段时间，在家休养时才感觉工作是多么的美好。

Quote

为庆祝劳动节，摘录一首儿歌

太阳光金亮亮
雄鸡唱三唱
花儿醒来了
鸟儿忙梳妆
小喜鹊造新房
小蜜蜂采蜜糖
幸福的生活从哪里来
要靠劳动来创造
青青的叶儿红红的花儿
小蝴蝶贪玩耍
不爱劳动不学习
我们大家不学它
要学喜鹊造新房
要学蜜蜂采蜜糖
劳动的快乐说不尽
劳动的创造最光荣

Program

If you send a request to and expect a response， many things may go wrong

1. your reqeust may have been lost

2. perhaps someone unplugged a network cable

3. your request may be waiting in a queue and will be delivered later

4. perhaps the network or the recipient is overloaded

5. the remote node may have failed

6. perhaps it crashed or it was powered down

7. the rmeote node may have temporialy stopped responding, but it will start responding again later

8. perhaps it is experiencing a long grabage collection pause

9. the remote node may have processed your request, but the response has been lost on the network

10. perhaps a network switch has been misconfigured

11. the remote node may have processed your request, but the response has been delayed and will be delivered later

12. perhaps the network or your own machine is overloaded

在C++中， 可调用对象可以是函数指针，函数对象，或者 lambda 表达式， 在现代 C++ 中，可以用 std::function 来统一包装上述三种可调用对象。

示例如下：

#include "run_example.h"

using namespace std;

int lessNnum(const int& a, const int& b) {
    return a<b?a:b;
}

class LessNum {
public:
    int operator()(const int& a, const int& b) {
        return a<b?a:b;
    }
};

int std_function_test(int argc, char* argv[])
{
    int a{3};
    int b{4};
    std::function<int(const int x, const int y)> compare;
    compare = lessNnum;
    cout << compare(a, b) << endl;

    compare = LessNum();
    cout << compare(a, b) << endl;

    compare = [](int a, int b) { return a<b?a:b; };
    cout << compare(a, b) << endl;

    return 0;
}

参见 https://github.com/walterfan/snippets/tree/master/cpp， 编译命令如下：

scons

运行如下命令

./bin/run_example -n std_function_test

结果为

3
3
3

English

The Reactive Manifesto

Published on September 16 2014. (v2.0)

Organisations working in disparate domains are independently discovering patterns for building software that look the same. These systems are more robust, more resilient, more flexible and better positioned to meet modern demands.

These changes are happening because application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday’s software architectures.

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

Reactive Systems are:

• Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.

• Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission-critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.

• Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.

• Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency. This boundary also provides the means to delegate failures as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead.

Large systems are composed of smaller ones and therefore depend on the Reactive properties of their constituents. This means that Reactive Systems apply design principles so these properties apply at all levels of scale, making them composable. The largest systems in the world rely upon architectures based on these properties and serve the needs of billions of people daily. It is time to apply these design principles consciously from the start instead of rediscovering them each time.