最后更新时间 2023-07-07.
macwk.com 在 2022-10-05 关站,域名停止解析,已经打不开了。
翻了很多资料,收集了几个网站作为替代,大家有需要可以试试,如果有更好的麻烦告诉我哈哈!
网站语言为中文,资源免费,推荐:
网站语言为英文,资源免费,推荐:
网站语言为中文,部分软件需要会员或赞助才能下载,不推荐:
最后更新时间 2023-07-07.
macwk.com 在 2022-10-05 关站,域名停止解析,已经打不开了。
翻了很多资料,收集了几个网站作为替代,大家有需要可以试试,如果有更好的麻烦告诉我哈哈!
网站语言为中文,资源免费,推荐:
网站语言为英文,资源免费,推荐:
网站语言为中文,部分软件需要会员或赞助才能下载,不推荐:
最后更新时间 2023-01-24.
笔者所在公司技术栈为 Golang + PHP,目前部分项目已经逐步转 Go 语言重构,部分 PHP 业务短时间无法用 Go 重写。
相比 Go 语言,互联网公司常见的 Nginx + PHP-FPM 模式,经常会出现性能问题——
特别是我们的活动业务,尽管底层用了鸟哥的 Yaf 框架,
但由于业务逻辑繁重,即使框架层面上完全零损耗,常常支撑不了流量高峰。
一旦某个时间段开启活动,虚拟机的扩容真的非常痛苦。
SRE、开发、QA 三方经常需要因为某个运营活动的进行,提前压测预估容量。
目前活动业务已经逐步用 Go 语言改造,此处不具体展开,防止跑题哈哈。
正因为 PHP 虚拟机模式,每次扩容需要流量剔除、克隆、操作负载均衡、验证流量等等,
推进 PHP 容器化就显得格外重要。
公司在去年年中,已经开始进行 PHP 容器化,不过由于项目优先级以及人力原因,进度较为迟缓。
nginx 发生了 502,很多时候是后端,也就是 php-fpm 不在工作。
我们的 PHP 业务的 Pod,由以下 5 个容器组成:
日常听说 HTTPS 是加密协议,那现实中的 HTTPS 流量,是真的完全加密吗?
——答案是,不一定。原因嘛,抓个包就知道了。
我们用 curl 命令触发一下:
curl -v 'https://s-api.37.com.cn/api/xxx'
* Trying 106.53.109.63:443...
* Connected to s-api.37.com.cn (106.53.109.63) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.37.com.cn
* start date: Aug 24 00:00:00 2022 GMT
* expire date: Sep 11 23:59:59 2023 GMT
* subjectAltName: host "s-api.37.com.cn" matched cert's "*.37.com.cn"
* issuer: C=US; O=DigiCert, Inc.; CN=RapidSSL Global TLS RSA4096 SHA256 2022 CA1
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* h2h3 [:method: GET]
* h2h3 [:path: /api/xxx]
* h2h3 [:scheme: https]
* h2h3 [:authority: s-api.37.com.cn]
* h2h3 [user-agent: curl/7.85.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x159813400)
> GET /api/xxx HTTP/2
> Host: s-api.37.com.cn
> user-agent: curl/7.85.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 404
< date: Wed, 18 Jan 2023 09:57:12 GMT
< content-type: text/html
< content-length: 150
<
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>openresty</center>
</body>
</html>
* Connection #0 to host s-api.37.com.cn left intact
Wireshark 使用过滤条件 ip.addr == 106.53.109.63
,截图如下:
Go 自带接口性能分析工具 pprof,较为常用的有以下 4 种分析:
接入方式:
主从同步,就是将数据冗余备份,主库(Master)将自己库中的数据,同步给从库(Slave)。
从库可以一个,也可以多个,如图所示:
Redis 虽然有 RDB 和 AOF 持久化技术,可以在服务器重启的情况下保证内存中的数据不会丢失(但不意味着数据不丢,重启的时候还是会有不可用的情况)。
但是如果服务器关闭后,再也起不来了(比如硬件故障),那意味着数据是完全丢失的!会对业务产生重大影响。
所以,主从同步的必要性,在于数据的高可用。它可以保证机器故障时,还有其他的服务器可以进行故障转移。
问题来了,多台服务器冗余同一份数据,Redis 是如何保证数据的一致性的?